[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RFC2630-bis comment



Jim,

But that is only true if the attribute values were DER-encoded in the
correct order by the signer as part of the process of calculating the
hash value.  Therefore, I agree with Russ that the RFC2630 requirement
that "Each SignedAttribute in the SET MUST be DER encoded." should not
be changed.

===========================================
John Pawling, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Jim Schaad [mailto:jimsch@xxxxxxxxxx]
Sent: Wednesday, December 05, 2001 11:22 PM
To: 'Housley, Russ'; jimsch@xxxxxxxxxx
Cc: ietf-smime@xxxxxxx
Subject: RE: RFC2630-bis comment



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
>