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: owner-ietf-smime@xxxxxxxxxxxx > [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Housley, Russ > Sent: Wednesday, December 05, 2001 3:15 PM > To: jimsch@xxxxxxxxxx > Cc: ietf-smime@xxxxxxx > Subject: 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 >