Blake,
The last time that I talked to Russ, he supports 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."
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.
Is there a good reason to have the authenticatedAttributes at the sender
in DER format for the purpose of calculating the signature, and then
reorder them to put them in the message?
Not that I know of.
And in the event that we mandate DER encoding on transmission, I propose
that receiving agents MUST NOT attempt to recode the attributes as DER.
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.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================