Re: Need help with understanding the DERSet ordering

SignedAttributes is a SET ... OF ... it just has a notional size limitation.

Regards,

David

PS. as an aside, the DER SET OF rule actually works fine (at least for
our purposes) for DER SET.
 
On 20/08/18 02:17, Christopher Snyder wrote:
> Hi, David. 
>
> Yes, that makes sense for Set-of but when I trace through RFC 5652 I see:
>
> SignedData ::= SEQUENCE {
>         …,
>         signerInfos SignerInfos }
> SignerInfos ::= SET OF SignerInfo
> SignerInfo ::= SEQUENCE {
>         …,
>         signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
>         … }
>
> SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
>
> Attribute ::= SEQUENCE {
>         attrType OBJECT IDENTIFIER,
>         attrValues SET OF AttributeValue }
>
> Since SignedAtttributes are defined as a SET and not SET-of how does
> 11.6 transfer through?
>
> Thanks,
> Chris
>
>
>> On Aug 19, 2018, at 2:58 AM, David Hook <dgh-rTAZ0PM/[email protected]
>> <mailto:dgh-rTAZ0PM/[email protected]>> wrote:
>>
>>
>> See section 11.6 of X.690
>>
>> Regards,
>>
>> David
>>
>> On 17/08/18 10:55, Christopher Snyder wrote:
>>> Perhaps in this situation the DERSet is treated as a DERSet-of which
>>> would explain the ordering that is being applied. I still would like
>>> to know where this treatment is specified in the documentation if
>>> someone can point it out.
>>>
>>> Thanks,
>>> Chris
>>>
>>>> On Aug 15, 2018, at 12:20 AM, Christopher Snyder
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> For the signed attributes in the CMS syntax and the DER encoding of
>>>> the signed attribute set, I’m confused about where in the
>>>> specifications does it specify the set ordering when a class of
>>>> tags have the same tag number. From the specs
>>>>
>>>> From X.690
>>>> 10.3 Set components
>>>> The encodings of the component values of a set value shall appear
>>>> in an order determined by their tags as specified in 8.6 of ITU-T
>>>> Rec. X.680 | ISO/IEC 8824-1.
>>>>
>>>> When i look at section 8.6 it says:
>>>> From X.680
>>>> 8.6 The canonical order for tags is based on the outermost tag of
>>>> each type and is defined as follows:
>>>> • a)  those elements or alternatives with universal class tags
>>>> shall appear first, followed by those with application class tags,
>>>> followed by those with context-specific tags, followed by those
>>>> with private class tags;
>>>> • b)  within each class of tags, the elements or alternatives shall
>>>> appear in ascending order of their tag numbers.
>>>>
>>>> In the BC DERSet code, I can see a sort is done based on the
>>>> encoding of each set element. I’m not clear on how that sorting is
>>>> covered by 8.6 in this case. If the signed attributes are all
>>>> sequences wouldn’t that mean that they all have the same tag
>>>> numbers and that the order of elements would be determined by how
>>>> they were sent?
>>>>
>>>> I think the BC is doing the right thing, I just don’t understand
>>>> where it is covered in the specification.
>>>>
>>>> Thank you,
>>>> Chris
>>>
>>>
>>
>>
>