[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC2630-bis comment


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

At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
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