Jim:
So, you just agreed that the SET must be DER encoded. I think that is what
the document says. What am I missing?
Russ
At 08:21 PM 12/5/2001 -0800, Jim Schaad wrote:
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
>