This message initiates an SMIME Working Group Last Call on the document:
Title : Multiple Signatures in S/MIME
Author(s) : S. Turner and J. Schaad
Filename : draft-ietf-smime-multisig-03.txt
Pages : 19
Date : 2007-11-16
I have two minor comments:
1 - On page 5, the last line refers to section 4.3. However, it is unclear why.
2 - In the security considerations section, the third paragraph states:
This attribute provides no protection if all of the algorithms used
in the signer attribute are 'cracked'.
This is not always true. If two different one way functions exhibit collisions,
finding a message where a collision may be found *at the same time*
for each one way function may not be straightforward.
Denis
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.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-03.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Standards Track RFC.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may be
sent to the document editor.
The Last Call period will end on 9 Janurary 2008.
Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to ensure
the quality of our documents and of the Internet Standards process. So,
please read and comment!
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com