I believe that the issue is whether CMS should mandate that the signedData
signerInfo authenticatedAttributes must be ordered as per the DER during
transmission. There were sidebar discussions at the LA IETF in which some
of us came up with the following proposal: "CMS should mandate that each
individual authenticatedAttribute MUST be DER-encoded and the SET OF
authenticatedAttributes MUST be ordered as per DER when they are digested to
generate or verify the signedData signerInfo signature value. Furthermore,
CMS should mandate that each individual authenticatedAttribute MUST be
DER-encoded when it is transmiited, but the SET OF authenticatedAttributes
need not be ordered as per DER when they are transmitted." In other words,
the authenticatedAttributes can be transmitted in any order and the
receiving software MUST ensure that they are ordered as per DER before
digesting them to verify the signature.
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
At 02:04 PM 4/15/98 -0700, Blake Ramsdell wrote:
On Wednesday, April 15, 1998 9:40 AM, Darren Harter
I agree with Russ' proposal to mandate the encoding of
authenticatedAttributes in DER.
Is it an error to try to re-encode the attributes as DER on an incoming
message? Granted you cannot re-encode the attribute values, but the
outer SET OF can be reordered according to DER.
We may want to point this out in the spec. I know that our products
reorder the outer SET OF for an incoming message according to DER (for
better or worse), and then do the signature validation. This actually
led to an incompatibility with another product that got fixed, but we
can avoid it in the future by saying that receiving applications MUST
NOT reorder the attributes according to DER.
Blake C. Ramsdell
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060