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

The IESG <> Tue, 27 May 2008 13:44 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id C559B3A6C33; Tue, 27 May 2008 06:44:06 -0700 (PDT)
Received: by (Postfix, from userid 30) id 6DA9F3A692C; Tue, 27 May 2008 06:44:05 -0700 (PDT)
X-idtracker: yes
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard
Message-Id: <>
Date: Tue, 27 May 2008 06:44:05 -0700
Cc: Internet Architecture Board <>, smime chair <>, smime mailing list <>, RFC Editor <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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:

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.


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

b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)".

c) In section 2 list item 1), please make the following substitution


If both SignerInfo objects are not present, the relying party
can easily determine that another SignerInfo has been removed.


Relying parties can easily determine that a SignerInfo has been removed
another SignerInfo contains a multi-sig attribute that refers to it.

d) In section 8.1, Normative References, please make the following


[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.


[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