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(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley,
Russ
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
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