Need help with understanding the DERSet ordering

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Need help with understanding the DERSet ordering

Christopher Snyder
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
Reply | Threaded
Open this post in threaded view
|

Re: Need help with understanding the DERSet ordering

Christopher Snyder
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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Need help with understanding the DERSet ordering

David Hook-3

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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Need help with understanding the DERSet ordering

Christopher Snyder
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 <[hidden email]> 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 <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Need help with understanding the DERSet ordering

David Hook-3

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 <[hidden email]> 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 <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

Re: Need help with understanding the DERSet ordering

Christopher Snyder
LOL, ok, now I see. Thank you so much for pointing that out!

Sincerely,
Chris

On Aug 19, 2018, at 6:57 PM, David Hook <[hidden email]> wrote:


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 <[hidden email]> 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 <[hidden email]> 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