[Top] [All Lists]

RE: RFC2630-bis comment

2001-12-05 21:21:42


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.  


-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley, 
Sent: Wednesday, December 05, 2001 3:15 PM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: RFC2630-bis comment


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.


At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:

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


<Prev in Thread] Current Thread [Next in Thread>