Multiple Signatures in Cryptographic Message Syntax (CMS)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, smime mailing list <email@example.com>, smime chair <firstname.lastname@example.org> Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard The IESG has approved the following document: - 'Multiple Signatures in S/MIME ' <draft-ietf-smime-multisig-05.txt> as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-05.txt
Technical Summary CMS SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Working Group Summary This ID was discussed on the smime mailing list and at several IETF meetings. Initially, there was some confusion about the problem being solved but moving the general attacks against CMS hashes text to an Appendix addressed the WG's concerns. This initial confusion has really been the only major issue. Document Quality This document is new and there are no implementations - yet. There has been interest from multiple vendors about when it will be published as an RFC. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note Please make the following changes: a) Please remove the "Discussion" section preceding the Table of Contents. b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)". c) In section 2 list item 1), please make the following substitution OLD If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. NEW Relying parties can easily determine that a SignerInfo has been removed if another SignerInfo contains a multi-sig attribute that refers to it. d) In section 8.1, Normative References, please make the following substitution: OLD [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. NEW [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.