Network Working Group R. Housley
Request for Comments: 4853 Vigil Security
Updates: 3852 April 2007
Category: Standards Track
Network Working Group R. Housley
Request for Comments: 4853 Vigil Security
Updates: 3852 April 2007
Category: Standards Track
Cryptographic Message Syntax (CMS) Multiple Signer Clarification
加密消息语法（CMS）多签名者澄清
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present.
本文档更新了RFC 3852中发布的加密消息语法（CMS）。本文档阐明了当存在多个数字签名时，如何正确处理SignedData保护的内容类型。
This document updates the Cryptographic Message Syntax [CMS]. The CMS SignedData protected content type allows multiple digital signatures, but the specification is unclear about the appropriate processing by a recipient of such a signed content. This document provides replacement text for a few paragraphs, making it clear that the protected content is validly signed by a given signer, if any of the digital signatures from that signer are valid.
本文档更新了加密消息语法[CMS]。CMS SignedData protected content type允许多个数字签名，但该规范不清楚收件人对此类签名内容的适当处理。本文档为几个段落提供了替换文本，明确了受保护内容由给定签名人有效签名（如果该签名人的任何数字签名有效）。
This property is especially important in two cases. First, when the recipients do not all implement the same digital signature algorithm, a signer can sign the content with several different digital signature algorithms so that each of the recipients can find an acceptable signature. For example, if some recipients support RSA and some recipients support ECDSA, then the signer can generate two signatures, one with RSA and one with ECDSA, so that each recipient will be able to validate one of the signatures. Second, when a community is transitioning one-way hash functions or digital signature algorithms, a signer can sign the content with the older and the newer signature algorithms so that each recipient can find an acceptable signature, regardless of their state in the transition. For example, consider a transition from RSA with SHA-1 to RSA with SHA-256. The signer can generate two signatures, one with SHA-1 and one with SHA-256, so that each recipient will be able to validate at least one of the RSA signatures.
这一特性在两种情况下尤为重要。首先，当收件人不都实现相同的数字签名算法时，签名者可以使用几种不同的数字签名算法对内容进行签名，以便每个收件人都可以找到一个可接受的签名。例如，如果某些收件人支持RSA，而某些收件人支持ECDSA，那么签名者可以生成两个签名，一个使用RSA，一个使用ECDSA，这样每个收件人都可以验证其中一个签名。其次，当社区正在转换单向散列函数或数字签名算法时，签名者可以使用较旧和较新的签名算法对内容进行签名，以便每个收件人都可以找到可接受的签名，而不管其在转换中的状态如何。例如，考虑从RSA到SHA-1到RSA与SHA256的转换。签名者可以生成两个签名，一个是SHA-1，一个是SHA-256，这样每个接收者都可以验证至少一个RSA签名。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
RFC 3852, section 5, the next to the last paragraph says:
RFC 3852第5节，最后一段的下一段说：
| A recipient independently computes the message digest. This message
| digest and the signer's public key are used to verify the signature
| value. The signer's public key is referenced either by an issuer
| distinguished name along with an issuer-specific serial number or by
| a subject key identifier that uniquely identifies the certificate
| containing the public key. The signer's certificate can be included
| in the SignedData certificates field.
| A recipient independently computes the message digest. This message
| digest and the signer's public key are used to verify the signature
| value. The signer's public key is referenced either by an issuer
| distinguished name along with an issuer-specific serial number or by
| a subject key identifier that uniquely identifies the certificate
| containing the public key. The signer's certificate can be included
| in the SignedData certificates field.
This block of text is replaced with:
此文本块替换为：
| A recipient independently computes the message digest. This message
| digest and the signer's public key are used to verify the signature
| value. The signer's public key is referenced either by an issuer
| distinguished name along with an issuer-specific serial number or by
| a subject key identifier that uniquely identifies the certificate
| containing the public key. The signer's certificate can be included
| in the SignedData certificates field.
|
| When more than one signature is present, the successful validation
| of one signature associated with a given signer is usually treated
| as a successful signature by that signer. However, there are some
| application environments where other rules are needed. An
| application that employs a rule other than one valid signature for
| each signer must specify those rules. Also, where simple matching of
| the signer identifier is not sufficient to determine whether the
| signatures were generated by the same signer, the application
| specification must describe how to determine which signatures were
| generated by the same signer. Support of different communities of
| recipients is the primary reason that signers choose to include more
| than one signature. For example, the signed-data content type might
| include signatures generated with the RSA signature algorithm and
| with the ECDSA signature algorithm. This allows recipients to
| verify the signature associated with one algorithm or the other.
| A recipient independently computes the message digest. This message
| digest and the signer's public key are used to verify the signature
| value. The signer's public key is referenced either by an issuer
| distinguished name along with an issuer-specific serial number or by
| a subject key identifier that uniquely identifies the certificate
| containing the public key. The signer's certificate can be included
| in the SignedData certificates field.
|
| When more than one signature is present, the successful validation
| of one signature associated with a given signer is usually treated
| as a successful signature by that signer. However, there are some
| application environments where other rules are needed. An
| application that employs a rule other than one valid signature for
| each signer must specify those rules. Also, where simple matching of
| the signer identifier is not sufficient to determine whether the
| signatures were generated by the same signer, the application
| specification must describe how to determine which signatures were
| generated by the same signer. Support of different communities of
| recipients is the primary reason that signers choose to include more
| than one signature. For example, the signed-data content type might
| include signatures generated with the RSA signature algorithm and
| with the ECDSA signature algorithm. This allows recipients to
| verify the signature associated with one algorithm or the other.
RFC 3852, section 5.1, the next to the last paragraph says:
RFC 3852，第5.1节，最后一段的下一段说：
| signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. The
| details of the SignerInfo type are discussed in section 5.3.
| Since each signer can employ a digital signature technique and
| future specifications could update the syntax, all implementations
| MUST gracefully handle unimplemented versions of SignerInfo.
| Further, since all implementations will not support every possible
| signature algorithm, all implementations MUST gracefully handle
| unimplemented signature algorithms when they are encountered.
| signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. The
| details of the SignerInfo type are discussed in section 5.3.
| Since each signer can employ a digital signature technique and
| future specifications could update the syntax, all implementations
| MUST gracefully handle unimplemented versions of SignerInfo.
| Further, since all implementations will not support every possible
| signature algorithm, all implementations MUST gracefully handle
| unimplemented signature algorithms when they are encountered.
This block of text is replaced with:
此文本块替换为：
| signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. When
| the collection represents more than one signature, the successful
| validation of one of signature from a given signer ought to be
| treated as a successful signature by that signer. However,
| there are some application environments where other rules are
| signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. When
| the collection represents more than one signature, the successful
| validation of one of signature from a given signer ought to be
| treated as a successful signature by that signer. However,
| there are some application environments where other rules are
| needed. The details of the SignerInfo type are discussed in
| section 5.3. Since each signer can employ a different digital
| signature technique, and future specifications could update the
| syntax, all implementations MUST gracefully handle unimplemented
| versions of SignerInfo. Further, since all implementations will
| not support every possible signature algorithm, all
| implementations MUST gracefully handle unimplemented signature
| algorithms when they are encountered.
| needed. The details of the SignerInfo type are discussed in
| section 5.3. Since each signer can employ a different digital
| signature technique, and future specifications could update the
| syntax, all implementations MUST gracefully handle unimplemented
| versions of SignerInfo. Further, since all implementations will
| not support every possible signature algorithm, all
| implementations MUST gracefully handle unimplemented signature
| algorithms when they are encountered.
The replacement text will reduce the likelihood of interoperability errors during the transition from MD5 and SHA-1 to stronger one-way hash functions, or to better signature algorithms.
替换文本将减少从MD5和SHA-1过渡到更强的单向散列函数或更好的签名算法期间出现互操作性错误的可能性。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。