ietf-smime
[Top] [All Lists]

RE: Authenticated Attributes DER vs BER

1998-04-16 13:36:26
On Thursday, April 16, 1998 1:22 PM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
"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."  

The alternative proposal is: "CMS mandates 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 AND when
they
are transmitted.

Personally, I don't care which proposal gets accepted.

I vote, er, am in favor of the alternative proposal -- everything is DER
in the authenticatedAttributes.

I respectfully disagree.  Many S/MIME receiving agents will totally
decode
the received CMS signedData and then re-DER-encode the
authenticatedAttributes to be digested to support a signature
verification.
Therefore, when they re-encode the SET OF authenticatedAttributes,
they
will
enforce the DER ordering rules.  If everybody is implementing DER
correctly,
then this is not a problem.  If somebody's code does DER incorrectly,
then
they should fix their code.

In the spirit of "being liberal in what you accept" and
interoperability, I think some language is needed.  How about "receiving
agents SHOULD NOT reorder the SET OF according to DER"?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060