Subject: RFC2630-bis comment

From: "Jim Schaad" <[email-masked]>
Date: Wed, 5 Dec 2001 13:49:46 -0800

Russ,

I believe that the requirement in section 5.3 about DER encoding of
SignedAttributes is too restrictive.  The current statement is "Each
SignedAttribute in the SET MUST be DER encoded."  I believe that the
intended statement is really "Each AttributeValue in the
SignedAttributes SET MUST be DER encoded."

Here is my problem.  Assume that I have an attribute FOO with 3 values.
If I do the encode of the entire SignerInfo object in one shot, then I
cannot cause the sort of the the attribute values without doing a DER
encoding of the SignerInfo object.  It's easy to correctly DER encode an
attribute if the attribute values are correctly DER encoded, and this
deals with the potential problem of a third party having to decode and
re-encode the values.

Please make this change as it continues to statisfy the requirement
behind the added statement, but imposes the smallest requirement on the
implementors.

Jim

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 05 Dec 2001 18:14:31 -0500

Jim:

My understanding is that ASN.1 tool sets are not guaranteed to preserve the 
order with a SET on decode.  So, if the attribute has more than one value, 
then the values must be places in sort order to ensure that the originator 
and the recipient will compute the same hash value.  If the attribute 
values can be in an arbitrary ordering, a recipient cannot know the order 
used by the originator.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 5 Dec 2001 20:21:35 -0800

Russ,

While it is true that the order cannot be known after the decode, if you
re-encode the set of attributes the correct order will be obtained.  

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Wednesday, December 05, 2001 3:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: RFC2630-bis comment
> 
> 
> 
> Jim:
>

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 06 Dec 2001 08:59:42 -0500

Jim:

So, you just agreed that the SET must be DER encoded.  I think that is what 
the document says.  What am I missing?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Dec 2001 11:34:59 -0800

Russ,

No I did not agree with that.   SignedAttributes is

SignedAttributes ::= SET OF SignedAttribute

SignedAttribute ::= SET OF Attribute

Attribute ::= SEQUENCE {
   attrType OBJECT IDENTIFIER,
   attrValue  SET OF ANY
}

If I do a re-encode of SignedAttributes as part of the signature
creation/verification process, and I re-encode this as a DER encoding,
all three SETs will automatically be sorted during the encode process no
matter what their order is in the data I pass in.  The thing that cannot
be DER encoded during this process is the ANY values inside of the
attrValue SET.  This is what I don't know how to decode/re-encode during
the process.  With the way that I have setup my encode of the SignedInfo
structure, I don't encode the attrValue SET using DER, but using BER
rules (i.e. no sort operation).  If John or anybody else decodes the
entire SignedInfo structure, re-encodes the SignedAttributes section
they will get the correct sequence of bytes to hash (assuming that the
ANYs are correctly DER encoded).

As the language currently stands, I need to encode SignedAttribute using
the DER encoding rules and then can encode SignedAttributes using the
BER encoding rules.  This does not make sense to me.

jim

> Sent: Thursday, December 06, 2001 6:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: RFC2630-bis comment
> 
> 
> 
> Jim:
>