Readers of this list are likely to recognize that the CMS specification, which underlies some SMIME RFCs, defines ASN.1 cryptographic data layouts that are used in EDIINT application statements (AS1, AS2, …) A proposed revision is under discussion that may be of interest to this group as it could impact underlying implementations eventually.Cryptographic Message Syntax (CMS) Multiple Signer Clarification<draft-ietf-smime-cms-mult-sign-01.txt>
Normally, multiple signers are not used in EDIINT messages,
but they could occur
because CMS allows them. The internet-draft says (and please read it for the exact
language) that when receiving CMS messages with multiple signatures, the default rule (as I will call it) will be
that the message is OK if one of the signatures is OK. It also mentions that certain
communities may wish to have a different rule that replaces the default rule. One justification for the default rule is that it will
promote interoperability for use cases in which an old and a new certificate are both used, and the signers want to provide signatures using both the old and the
new certificate (which may have different strengths, use new improved hashes,
etc). That way, receivers who have not managed to update their systems (even
after using CEM!) may still validate the signatures and continue operations. I have not seen much discussion about security threats or
risks that might arise from adhering to this rule. Because changes to CMS options may impact security toolkits,
it is worth considering whether readers of this group have any questions for
the security group that is considering this change. Please send questions or assessment of risks or
threats to them. |