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(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley,
Russ
Sent: Thursday, December 06, 2001 6:00 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
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(_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