RE: RFC2630-bis comment

["Jim Schaad" <jimsch@xxxxxxxxxx>]

Russ,

No I did not agree with that.   SignedAttributes is

SignedAttributes ::= SET OF SignedAttribute

SignedAttribute ::= SET OF Attribute

Attribute ::= SEQUENCE {
   attrType OBJECT IDENTIFIER,
   attrValue  SET OF ANY
}

If I do a re-encode of SignedAttributes as part of the signature
creation/verification process, and I re-encode this as a DER encoding,
all three SETs will automatically be sorted during the encode process no
matter what their order is in the data I pass in.  The thing that cannot
be DER encoded during this process is the ANY values inside of the
attrValue SET.  This is what I don't know how to decode/re-encode during
the process.  With the way that I have setup my encode of the SignedInfo
structure, I don't encode the attrValue SET using DER, but using BER
rules (i.e. no sort operation).  If John or anybody else decodes the
entire SignedInfo structure, re-encodes the SignedAttributes section
they will get the correct sequence of bytes to hash (assuming that the
ANYs are correctly DER encoded).

As the language currently stands, I need to encode SignedAttribute using
the DER encoding rules and then can encode SignedAttributes using the
BER encoding rules.  This does not make sense to me.

jim

> -----Original Message-----
> From: owner-ietf-smime@xxxxxxxxxxxx 
> [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Housley, Russ
> Sent: Thursday, December 06, 2001 6:00 AM
> To: jimsch@xxxxxxxxxx
> Cc: ietf-smime@xxxxxxx
> Subject: RE: RFC2630-bis comment
> 
> 
> 
> 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@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
> > >
>