[Top] [All Lists]

RE: RFC2630-bis comment

2001-12-06 07:03:20


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


At 08:21 PM 12/5/2001 -0800, Jim Schaad wrote:

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
> 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

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