Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 27 May 2008 06:44:05 -0700 (PDT)

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.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce