Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5752 IECA
Category: Standards Track J. Schaad
ISSN: 2070-1721 Soaring Hawk
January 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5752 IECA
Category: Standards Track J. Schaad
ISSN: 2070-1721 Soaring Hawk
January 2010
Multiple Signatures in Cryptographic Message Syntax (CMS)
加密消息语法（CMS）中的多个签名
Abstract
摘要
Cryptographic Message Syntax (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 objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration.
加密消息语法（CMS）SignedData包括SignerInfo结构，用于传递每个签名者的信息。SignedData支持多个签名者以及具有多个SignerinInfo结构的每个签名者的多个签名算法。如果一个签名者附加了多个SignerInfo，攻击者可能会通过使用“强”算法删除SignerInfo来执行降级攻击。本文档定义了“多个签名”属性、其生成规则和处理规则，以允许签名者传递多个SignerInfo对象，同时防止降级攻击。此外，此属性在算法迁移期间可能会有所帮助。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5752.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5752.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Rationale .......................................................3
2.1. Attribute Design Requirements ..............................4
3. Multiple Signature Indication ...................................5
4. Message Generation and Processing ...............................6
4.1. SignedData Type ............................................6
4.2. EncapsulatedContentInfo Type ...............................7
4.3. SignerInfo Type ............................................7
4.4. Message Digest Calculation Process .........................7
4.4.1. multiple-signatures Signed Attribute Generation .....7
4.4.2. Message Digest Calculation Process ..................7
4.5. Signature Generation Process ...............................8
4.6. Signature Verification Process .............................8
5. Signature Evaluation Processing .................................8
5.1. Evaluation of a SignerInfo Object ..........................9
5.2. Evaluation of a SignerInfo Set .............................9
5.3. Evaluation of a SignedData Set ............................10
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Appendix A. ASN.1 Module...........................................13
Appendix B. Background.............................................15
B.1. Attacks....................................................15
B.2. Hashes in CMS..............................................15
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Rationale .......................................................3
2.1. Attribute Design Requirements ..............................4
3. Multiple Signature Indication ...................................5
4. Message Generation and Processing ...............................6
4.1. SignedData Type ............................................6
4.2. EncapsulatedContentInfo Type ...............................7
4.3. SignerInfo Type ............................................7
4.4. Message Digest Calculation Process .........................7
4.4.1. multiple-signatures Signed Attribute Generation .....7
4.4.2. Message Digest Calculation Process ..................7
4.5. Signature Generation Process ...............................8
4.6. Signature Verification Process .............................8
5. Signature Evaluation Processing .................................8
5.1. Evaluation of a SignerInfo Object ..........................9
5.2. Evaluation of a SignerInfo Set .............................9
5.3. Evaluation of a SignedData Set ............................10
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Appendix A. ASN.1 Module...........................................13
Appendix B. Background.............................................15
B.1. Attacks....................................................15
B.2. Hashes in CMS..............................................15
The Cryptographic Message Syntax (CMS; see [CMS]) defined SignerInfo to provide data necessary for relying parties to verify the signer's digital signature, which is also included in the SignerInfo structure. Signers include more than one SignerInfo in a SignedData if they use different digest or signature algorithms. Each SignerInfo exists independently and new SignerInfo structures can be added or existing ones removed without perturbing the remaining signatures.
加密消息语法（CMS；参见[CMS]）定义了SignerInfo，以提供依赖方验证签名人数字签名所需的数据，该数字签名也包含在SignerInfo结构中。如果签名者使用不同的摘要或签名算法，则在SignedData中包含多个SignerInfo。每个SignerInfo独立存在，可以添加或删除新的SignerInfo结构，而不会干扰其余的签名。
The concern is that if an attacker successfully attacked a hash or signature algorithm, the attacker could remove all SignerInfo structures except the SignerInfo with the successfully attacked hash or signature algorithm. The relying party is then left with the attacked SignerInfo even though the relying party supported more than just the attacked hash or signature algorithm.
令人担忧的是，如果攻击者成功攻击哈希或签名算法，则攻击者可能会删除除使用成功攻击的哈希或签名算法的SignerInfo之外的所有SignerInfo结构。然后，即使依赖方支持的不仅仅是受攻击的哈希或签名算法，依赖方仍会保留受攻击的SignerInfo。
A solution is to have signers include a pointer to all the signer's SignerInfo structures. If an attacker removes any SignerInfo, then relying parties will be aware that an attacker has removed one or more SignerInfo objects.
解决方案是让签名者包含一个指向所有签名者的SignerinInfo结构的指针。如果攻击者删除了任何SignerInfo，则依赖方将知道攻击者删除了一个或多个SignerInfo对象。
Note that this attribute ought not be confused with the countersignature attribute (see Section 11.4 of [CMS]) as this is not intended to sign over an existing signature. Rather, it is to provide a pointer to additional signatures by the signer that are all at the same level. That is, countersignature provides a serial signature while the attribute defined herein provides pointers to parallel signatures by the same signer.
请注意，此属性不应与会签属性混淆（参见[CMS]第11.4节），因为这不是为了在现有签名上签名。相反，它是提供一个指向签名者在同一级别上的其他签名的指针。也就是说，会签提供串行签名，而本文定义的属性提供指向同一签名者的并行签名的指针。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The rationale for this specification is to protect against downgrade attacks that remove the 'strong' signature to leave the 'weak' signature, which has presumably been successfully attacked. If a CMS SignedData object has multiple SignerInfo objects, then the attacker, whether it be Alice, Bob, or Mallory, can remove a SignerInfo object without the relying party being aware that more than one was generated.
本规范的基本原理是防止降级攻击，即删除“强”签名以保留“弱”签名，而“弱”签名可能已被成功攻击。如果CMS SignedData对象具有多个SignerInfo对象，则攻击者（无论是Alice、Bob还是Mallory）都可以删除SignerInfo对象，而依赖方不知道生成了多个SignerInfo对象。
Removal of a SignerInfo does not render the signature invalid nor does it constitute an error. In the following scenario, a signer generates a SignedData with two SignerInfo objects, one with a 'weak' algorithm and one with a 'strong' algorithm; there are three types of relying parties:
删除SignerInfo不会导致签名无效，也不会构成错误。在以下场景中，签名者使用两个SignerInfo对象生成SignedData，一个使用“弱”算法，另一个使用“强”算法；依赖方有三种类型：
1) Those that support only a 'weak' algorithm. If both SignerInfo objects are present, the relying party processes the algorithm it supports. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed, but not changed. In both cases, if the 'weak' signature verifies, the relying party MAY consider the signature valid.
1) 那些只支持“弱”算法的。如果两个SignerInfo对象都存在，依赖方将处理其支持的算法。如果两个SignerInfo对象都不存在，依赖方可以轻松确定另一个SignerInfo已被删除，但未被更改。在这两种情况下，如果“弱”签名验证，依赖方可以认为签名有效。
2) Those that support only a 'strong' algorithm. If both SignerInfo objects are present, the relying party processes the algorithm it supports. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed, but the relying party doesn't care. In both cases, if the 'strong' signature verifies, the relying party MAY consider the signature valid.
2) 那些只支持“强”算法的。如果两个SignerInfo对象都存在，依赖方将处理其支持的算法。如果两个SignerInfo对象都不存在，依赖方可以轻松确定另一个SignerInfo已被删除，但依赖方并不在意。在这两种情况下，如果“强”签名验证，依赖方可以认为签名有效。
3) Those that support both a 'weak' algorithm and a 'strong' algorithm. If both SignerInfo objects are present, the relying party processes both algorithms. If both SignerInfo objects are not present, the relying party can easily determine that another SignerInfo has been removed. In both cases, if the 'strong' and/or 'weak' signatures verify, the relying party MAY consider the signature valid. (Policy may dictate that both signatures are required to validate if present.)
3) 同时支持“弱”算法和“强”算法的。如果两个SignerInfo对象都存在，依赖方将处理这两个算法。如果两个SignerInfo对象都不存在，依赖方可以轻松确定另一个SignerInfo已被删除。在这两种情况下，如果“强”和/或“弱”签名验证，依赖方可以认为签名有效。（政策可能规定，如果存在，则需要两个签名进行验证。）
Local policy MAY dictate that the removal of the 'strong' algorithm results in an invalid signature. See Section 5 for further processing.
本地策略可能规定删除“强”算法会导致签名无效。有关进一步处理，请参见第5节。
The attribute will have the following characteristics:
该属性将具有以下特征：
1) Use CMS attribute structure;
1) 使用CMS属性结构；
2) Be computable before any signatures are applied;
2) 在应用任何签名之前可计算；
3) Contain enough information to identify individual signatures (i.e., a particular SignerInfo); and
3) 包含足够的信息以识别单个签名（即特定签名信息）；和
4) Contain enough information to resist collision, preimage, and second preimage attacks.
4) 包含足够的信息以抵抗碰撞、前映像和第二前映像攻击。
The multiple-signatures attribute type specifies a pointer to a signer's other multiple-signatures attribute(s). For example, if a signer applies three signatures, there must be two attribute values for multiple-signatures in each SignerInfo. The 1st SignerInfo object points to the 2nd and 3rd SignerInfo objects. The 2nd SignerInfo object points to the 1st and 3rd SignerInfo objects. The 3rd SignerInfo object points to the 1st and 2nd SignerInfo objects.
多重签名属性类型指定指向签名者的其他多重签名属性的指针。例如，如果一个签名者应用了三个签名，则每个SignerInfo中的多个签名必须有两个属性值。第一个SignerInfo对象指向第二个和第三个SignerInfo对象。第二个SignerInfo对象指向第一个和第三个SignerInfo对象。第三个SignerInfo对象指向第一个和第二个SignerInfo对象。
The multiple-signatures attribute MUST be a signed attribute. The number of attribute values included in a SignerInfo is the number of signatures applied by a signer less one. This attribute is multi-valued, and there MAY be more than one AttributeValue present. The following object identifier identifies the multiple-signatures attribute:
“多个签名”属性必须是已签名属性。SignerInfo中包含的属性值数是签名者应用的签名数减去1。此属性是多值的，可能存在多个AttributeValue。以下对象标识符标识多个签名属性：
id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-aa(16) 51 }
id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-aa(16) 51 }
multiple-signatures attribute values have the ASN.1 type MultipleSignatures:
多重签名属性值具有ASN.1类型的多重签名：
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL}
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL}
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
The fields in MultipleSignatures have the following meaning:
多重符号中的字段具有以下含义：
- bodyHashAlg includes the digest algorithmIdentifier for the referenced multiple-signatures attribute.
- bodyHashAlg包含引用的多个签名属性的摘要算法标识符。
- signAlg includes the signature algorithmIdentifier for the referenced multiple-signatures attribute.
- signAlg包括引用的多个签名属性的签名算法标识符。
- signAttrsHash has two fields:
- signAttrsHash有两个字段：
-- algId MUST match the digest algorithm for the SignerInfo in which this multiple-signatures attribute value is placed.
--algId必须与放置此多个签名属性值的SignerInfo的摘要算法匹配。
-- hash is the hash value of the signedAttrs (see Section 4.3).
--hash是SignedAttr的哈希值（参见第4.3节）。
- cert is optional. It identities the certificate used to sign the SignerInfo that contains the other multiple-signatures attribute(s). It MUST be present if the fields in the other multiple-signatures attribute(s) are the same.
- 证书是可选的。它标识用于对包含其他多个签名属性的SignerInfo进行签名的证书。如果其他多个签名属性中的字段相同，则必须存在该属性。
The following is an example:
以下是一个例子：
SignedData
DigestAlg=sha1,sha256
SignerInfo1 SignerInfo2
digestAlg=sha1 digestAlg=sha256
signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256
signedAttrs= signedAttrs=
signingTime1 signingTime1
messageDigest1 messageDigest2
multiSig1= multiSig2=
bodyHash=sha256 bodyHash=sha1
signAlg=ecdsawithsha256 signAlg=dsawithsha1
signAttrsHash= signAttrsHash=
algID=sha1 algID=sha256
hash=value1 hash=value2
SignedData
DigestAlg=sha1,sha256
SignerInfo1 SignerInfo2
digestAlg=sha1 digestAlg=sha256
signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256
signedAttrs= signedAttrs=
signingTime1 signingTime1
messageDigest1 messageDigest2
multiSig1= multiSig2=
bodyHash=sha256 bodyHash=sha1
signAlg=ecdsawithsha256 signAlg=dsawithsha1
signAttrsHash= signAttrsHash=
algID=sha1 algID=sha256
hash=value1 hash=value2
The following are the additional procedures for message generation when using the multiple-signatures attribute. These paragraphs track with Sections 5.1-5.6 in [CMS].
以下是使用“多个签名”属性时生成消息的附加过程。这些段落与[CMS]中的第5.1-5.6节保持一致。
The following steps MUST be followed by a signer when generating SignedData:
生成SignedData时，签名者必须遵循以下步骤：
- The signer MUST indicate the CMS version.
- 签名者必须指明CMS版本。
- The signer SHOULD include the digest algorithm used in SignedData.digestAlgorithms, if the digest algorithm's identifier is not already present.
- 如果摘要算法的标识符不存在，签名者应包括SignedData.digestAlgorithms中使用的摘要算法。
- The signer MUST include the encapContentInfo. Note that the encapContentInfo is the same for all signers in this SignedData.
- 签名者必须包含encapContentInfo。请注意，encapContentInfo对于此SignedData中的所有签名者都是相同的。
- The signer SHOULD add certificates sufficient to contain certificate paths from a recognized "root" or "top-level certification authority" to the signer, if the signer's certificates are not already present.
- 如果签名者的证书尚未存在，则签名者应添加足以包含从已识别的“根”或“顶级证书颁发机构”到签名者的证书路径的证书。
- The signer MAY include the Certificate Revocation Lists (CRLs) necessary to validate the digital signature, if the CRLs are not already present.
- 如果CRL不存在，签名者可以包括验证数字签名所需的证书撤销列表（CRL）。
- The signer MUST:
- 签字人必须：
-- Retain the existing signerInfo objects.
--保留现有的signerInfo对象。
-- Include their signerInfo object(s).
--包括他们的signerInfo对象。
The procedures for generating EncapsulatedContentInfo are as specified in Section 5.2 of [CMS].
[CMS]第5.2节规定了生成封装内容信息的程序。
The procedures for generating SignerInfo are as specified in Section 4.4.1 of [CMS] with the following addition:
生成SignerInfo的程序如[CMS]第4.4.1节所述，并添加以下内容：
The signer MUST include the multiple-signatures attribute in signedAttrs.
签名者必须在signedAttrs中包含多个签名属性。
The procedure for generating the multiple-signatures signed attribute is as follows:
生成多重签名签名属性的过程如下所示：
1) All other signed attributes are placed in the respective SignerInfo structures, but the signatures are not yet computed for the SignerInfo.
1) 所有其他已签名属性都放置在各自的SignerInfo结构中，但尚未计算SignerInfo的签名。
2) The multiple-signatures attributes are added to each of the SignerInfo structures with the SignAttrsHash.hash field containing a zero-length octet string.
2) 使用包含零长度八位字节字符串的SignAttrsHash.hash字段，将多个签名属性添加到每个SignerInfo结构中。
3) The correct SignAttrsHash.hash value is computed for each of the SignerInfo structures.
3) 将为每个SignerInfo结构计算正确的SignAttrsHash.hash值。
4) After all hash values have been computed, the correct hash values are placed into their respective SignAttrsHash.hash fields.
4) 计算完所有哈希值后，将正确的哈希值放入各自的SignAttrsHash.hash字段中。
The remaining procedures for generating the message-digest attribute are as specified in Section 5.4 of [CMS].
生成消息摘要属性的其余步骤如[CMS]第5.4节所述。
The procedures for signature generation are as specified in Section 5.5 of [CMS].
签名生成程序如[CMS]第5.5节所述。
The procedures for signature verification are as specified in Section 5.6 of [CMS] with the following addition:
[CMS]第5.6节规定了签名验证程序，并增加了以下内容：
If the SignedData signerInfo includes the multiple-signatures attribute, the attribute's values must be calculated as described in Section 4.4.1.
如果SignedData signerInfo包含多个签名属性，则必须按照第4.4.1节中的说明计算该属性的值。
For every SignerInfo to be considered present for a given signer, the number of MultipleSignatures AttributeValue(s) present in a given SignerInfo MUST equal the number of SignerInfo objects for that signer less one and the hash value present in each of the MultipleSignatures AttributeValue(s) MUST match the output of the message digest calculation from Section 4.4.1 for each SignerInfo.
对于给定签名者的每个SignerInfo，给定签名者信息中的MultipleSignatures AttributeValue的数量必须等于该签名者的SignerInfo对象数量减去1和每个MultipleSignatures AttributeValue中的哈希值对于每个SignerInfo，必须与第4.4.1节中的消息摘要计算输出相匹配。
The hash corresponding to the n-th SignerInfo must match the value in the multiple-signatures attribute that points to the n-th SignerInfo present in all other SignerInfo objects.
与第n个SignerInfo对应的哈希必须与指向所有其他SignerInfo对象中存在的第n个SignerInfo的“多个签名”属性中的值匹配。
This section describes recommended processing of signatures when there are more than one SignerInfo present in a message. This may be due to either multiple SignerInfo objects being present in a single SignedData object or multiple SignerData objects embedded in each other.
本节介绍当消息中存在多个SignerinInfo时，建议对签名进行的处理。这可能是由于单个SignedData对象中存在多个SignerInfo对象，或者多个SignerData对象相互嵌入。
The text in this section is non-normative. The processing described is highly recommended, but is not forced. Changes in the processing that have the same results with somewhat different orders of processing is sufficient.
本节中的文本是非规范性的。强烈建议执行上述处理，但不是强制执行的。处理过程中的变化，如果具有相同的结果，但处理顺序略有不同，就足够了。
Order of operations:
操作顺序：
1) Evaluate each SignerInfo object independently.
1) 独立评估每个SignerInfo对象。
2) Combine the results of all SignerInfo objects at the same level (i.e., attached to the same SignerData object).
2) 合并同一级别上所有SignerInfo对象的结果（即，附加到同一SignerData对象）。
3) Combine the results of the nested SignerData objects. Note that this should ignore the presence of other CMS objects between the SignedData objects.
3) 合并嵌套SignerData对象的结果。注意，这应该忽略SignedData对象之间存在的其他CMS对象。
When evaluating a SignerInfo object, there are three different pieces that need to be examined.
评估SignerInfo对象时，需要检查三个不同的部分。
The first piece is the mathematics of the signature itself (i.e., can one actually successfully do the computations and get the correct answer?). This result is one of three results. The mathematics succeeds, the mathematics fails, or the mathematics cannot be evaluated. The type of things that lead to the last state are non-implementation of an algorithm or required inputs, such as the public key, are missing.
第一部分是签名本身的数学（即，一个人能否成功地进行计算并得到正确答案？）。这个结果是三个结果之一。数学成功，数学失败，或者数学无法评估。导致最后一种状态的类型是未实现算法或缺少必需的输入，如公钥。
The second piece is the validation of the source of the public key. For CMS, this is generally determined by extracting the public key from a certificate. The certificate needs to be evaluated. This is done by the procedures outlined in [PROFILE]. In addition to the processing described in that document, there may be additional requirements on certification path processing that are required by the application in question. One such set of additional processing is described in [SMIME-CERT]. One piece of information that is part of this additional certificate path processing is local and application policy. The output of this processing can actually be one of four different states: Success, Failure, Indeterminate, and Warning. The first three states are described in [PROFILE]; Warning would be generated when it is possible that some information is currently acceptable, but may not be acceptable either in the near future or under some circumstances.
第二部分是验证公钥的来源。对于CMS，这通常通过从证书中提取公钥来确定。需要对证书进行评估。这是通过[PROFILE]中概述的程序完成的。除了该文件中描述的处理外，可能还有相关应用程序所需的认证路径处理的附加要求。[SMIME-CERT]中描述了一组这样的附加处理。作为此附加证书路径处理一部分的一条信息是本地和应用程序策略。此处理的输出实际上可以是四种不同状态之一：成功、失败、不确定和警告。前三种状态在[PROFILE]中描述；当某些信息可能当前可接受，但在不久的将来或某些情况下可能不可接受时，将生成警告。
The third piece of the validation is local and application policy as applied to the contents of the SignerInfo object. This would cover such issues as the requirements on mandatory signed attributes or requirements on signature algorithms.
验证的第三部分是应用于SignerInfo对象内容的本地和应用程序策略。这将涉及诸如强制性签名属性要求或签名算法要求等问题。
Combining the results of the individual SignerInfo objects into a result for a SignedData object requires knowledge of the results for the individual SignerInfo objects, the required application policy, and any local policies. The default processing if no other rules are applied should be:
将单个SignerInfo对象的结果合并到SignedData对象的结果中需要了解单个SignerInfo对象的结果、所需的应用程序策略和任何本地策略。如果未应用其他规则，则默认处理应为：
1) Group the SignerInfo objects by the signer.
1) 按签名者对SignerInfo对象进行分组。
2) Take the best result from each signer.
2) 从每个签名者那里获得最佳结果。
3) Take the worst result from all of the different signers; this is the result for the SignedData object.
3) 从所有不同的签名者那里得到最坏的结果；这是SignedData对象的结果。
Application and local policy can affect each of the steps outlined above.
应用程序和本地策略可能会影响上述每个步骤。
In Step 1:
在步骤1中：
- If the subject name or subject alternative name(s) cannot be used to determine if two SignerInfo objects were created by the same identity, then applications need to specify how such matching is to be done. As an example, the S/MIME message specification [SMIME-MSG] could say that as long as the same rfc822Name exists in either the subject name or the subject alt name they are the same identity. This would be true even if other information that did not match existed in these fields.
- 如果无法使用使用者名称或使用者备选名称来确定两个SignerInfo对象是否由同一身份创建，则应用程序需要指定如何进行此类匹配。例如，S/MIME消息规范[SMIME-MSG]可以说，只要subject name或subject alt name中存在相同的RFC822名称，它们就是相同的标识。即使这些字段中存在其他不匹配的信息，这也是正确的。
- Some applications may specify that this step should be skipped; this has the effect of making each SignerInfo object independent of all other SignerInfo objects even if the signing identity is the same. Applications that specify this need to be aware that algorithm rollover will not work correctly in this case.
- 某些应用程序可能会指定跳过此步骤；这会使每个SignerInfo对象独立于所有其他SignerInfo对象，即使签名标识相同。指定这一点的应用程序需要知道，在这种情况下，算法滚动将无法正常工作。
In Step 2:
在步骤2中：
- The major policy implication at this step is the treatment of and order for the indeterminate states. In most cases, this state would be placed between the failure and warning states. Part of the issue is the question of having a multi-state or a binary answer as to success or failure of an evaluation. Not every application can deal with the statement "try again later". It may also be dependent on what the reason for the indeterminate state is. It makes more sense to try again later if the problem is that a CRL cannot be found than if you are not able to evaluate the algorithm for the signature.
- 这一步骤的主要政策含义是对不确定状态的处理和秩序。在大多数情况下，此状态将处于故障状态和警告状态之间。问题的一部分是关于评估成功与否的多状态或二元答案的问题。不是每个应用程序都可以处理“稍后再试”语句。这也可能取决于不确定状态的原因。如果问题是找不到CRL，而不是无法评估签名的算法，则稍后重试更有意义。
In Step 3:
在步骤3中：
- The same policy implications from Step 2 apply here.
- 第2步的相同政策含义适用于此处。
Simple applications will generally use the worst single outcome (success, unknown, failure) as the outcome for a set of SignedData objects (i.e., one failure means the entire item fails). However, not all applications will want to have this behavior.
简单应用程序通常使用最差的单一结果（成功、未知、失败）作为一组SignedData对象的结果（即，一个失败意味着整个项目失败）。但是，并非所有应用程序都希望有这种行为。
A work flow application could work as follows:
工作流应用程序可以按如下方式工作：
The second signer will modify the original content, keep the original signature, and then sign the message. This means that only the outermost signature is of significance during evaluation. The second signer is asserting that they successfully validated the inner signature as part of its processing.
第二个签名者将修改原始内容，保留原始签名，然后对邮件进行签名。这意味着在评估过程中，只有最外层的签名才有意义。第二个签名者声称他们成功地验证了内部签名作为其处理的一部分。
A Signed Mail application could work as follows:
签名邮件应用程序的工作方式如下：
If signatures are added for the support of [ESS] features, then the fact that an outer layer signature cannot be validated can be treated as a non-significant failure. The only thing that matters is that the originator signature is valid. This means that all outer layer signatures that fail can be stripped from the message prior to display leaving only the inner-most valid signature to be displayed.
如果为支持[ESS]功能而添加签名，则外层签名无法验证的事实可被视为非重大故障。唯一重要的是发起者签名是否有效。这意味着所有失败的外层签名可以在显示之前从消息中剥离，只留下最内层的有效签名。
Security considerations from the hash and signature algorithms used to produce the SignerInfo apply.
用于生成SignerInfo的哈希和签名算法的安全注意事项适用。
If the hashing and signing operations are performed by different entities, the entity creating the signature must ensure that the hash comes from a "trustworthy" source. This can be partially mitigated by requiring that multiple hashes using different algorithms are provided.
如果散列和签名操作由不同的实体执行，则创建签名的实体必须确保散列来自“可靠”的源。这可以通过要求提供使用不同算法的多个哈希来部分缓解。
This attribute cannot be relied upon in the event that all of the algorithms used in the signer attribute are 'cracked'. It is not possible for a verifier to determine that a collision could not be found that satisfies all of the algorithms.
如果签名者属性中使用的所有算法都被“破解”，则不能依赖此属性。验证器不可能确定无法找到满足所有算法的冲突。
Local policy and applications greatly affect signature processing. The application of local policy and the requirements specific to an application can both affect signature processing. This means that a signature valid in one context or location can fail validation in a different context or location.
本地策略和应用程序极大地影响签名处理。本地策略的应用和特定于应用程序的要求都会影响签名处理。这意味着在一个上下文或位置中有效的签名可能会在另一个上下文或位置中验证失败。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[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.
[PROFILE]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 52802008年5月。
[SMIME-CERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[SMIME-CERT]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 57502010年1月。
[SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME-MSG]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[ESSCertID] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[ESSCertID]Schaad，J.，“增强安全服务（ESS）更新：添加CertID算法敏捷性”，RFC 5035，2007年8月。
[ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[攻击]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
MultipleSignatures-2008
多重签名-2008
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0)
id-mod-multipleSig-2008(34) }
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0)
id-mod-multipleSig-2008(34) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS All
--全部出口
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
进口
-- Imports from RFC 5652 [CMS], 12.1
--从RFC 5652[CMS]进口，12.1
DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) cms-2004(24) }
DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 5035 [ESSCertID], Appendix A
--从RFC 5035[ESSCertID]进口，附录A
ESSCertIDv2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-ess-2006(30) }
ESSCertIDv2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-ess-2006(30) }
;
;
-- Section 3.0
--第3.0节
id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }
id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL }
MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL }
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
END -- of MultipleSignatures-2008
完2008年倍数符号的定义
This is an informational appendix. This appendix enumerates all locations in CMS where hashes are used and the possible attacks on those hash locations.
这是一个信息性附录。本附录列举了CMS中使用哈希的所有位置以及对这些哈希位置的可能攻击。
As noted in [ATTACK], the following types of resistance are needed against known attacks:
如[攻击]中所述，针对已知攻击需要以下类型的抵抗：
1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
2) Preimage Resistance: Given y, find x where H(x) = y
2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
Note: It is known that a collision resistance attack is simpler than a second preimage resistance attack, and it is presumed that a second preimage resistance attack is simpler than a preimage attack.
注：众所周知，碰撞抵抗攻击比第二个前映像抵抗攻击简单，并且假定第二个前映像抵抗攻击比前映像攻击简单。
Within a SignerInfo there are two places where hashes are applied and hence can be attacked: the body and the signed attributes. The following outlines the entity that creates the hash, the entity that attacks the hash, and the type of resistance required:
在SignerInfo中，有两个地方应用了哈希，因此可能受到攻击：主体和签名属性。以下概述了创建哈希的实体、攻击哈希的实体以及所需的抵抗类型：
1) Hash of the Body (i.e., the octets comprising the value of the encapContentInfo.eContent OCTET STRING omitting the tag and length octets, as per 5.4 of [CMS]).
1) 主体散列（即，根据[CMS]第5.4条，包含省略标记和长度八位字节的encapContentInfo.eContent八位字节字符串值的八位字节）。
a) If Alice creates the body to be hashed, then:
a) 如果Alice创建要散列的正文，则：
i) Alice can attack the hash. This attack requires a successful collision resistance attack.
i) 爱丽丝可以攻击散列。此攻击需要成功的抗碰撞攻击。
ii) Mallory can attack the hash. This attack requires a successful second preimage resistance attack.
ii）Mallory可以攻击哈希。此攻击需要成功的第二次前映像抵抗攻击。
b) If Alice hashes a body provided by Bob, then:
b) 如果Alice散列Bob提供的正文，则：
i) Alice can attack the hash. This attack requires a successful second preimage attack.
i) 爱丽丝可以攻击散列。此攻击需要成功的第二次前映像攻击。
ii) Bob can attack the hash. This attack requires a successful Collision Resistance attack. If Alice has the ability to "change" the content of the body in some fashion, then this attack requires a successful second preimage attack. (One example would be to use a keyed hash function.)
ii）Bob可以攻击散列。此攻击需要成功的抗碰撞攻击。如果Alice能够以某种方式“更改”身体的内容，则此攻击需要成功的第二次前图像攻击。（一个例子是使用键控哈希函数。）
iii) Mallory can attack the hash. This attack requires a successful second preimage attack.
iii）Mallory可以攻击哈希。此攻击需要成功的第二次前映像攻击。
c) If Alice signs using a hash value provided by Bob (in this case, Alice is presumed to never see the body in question), then:
c) 如果Alice使用Bob提供的散列值进行签名（在本例中，Alice被假定从未见过相关的尸体），则：
i) Alice can attack the hash. This attack requires a successful preimage attack.
i) 爱丽丝可以攻击散列。此攻击需要成功的前映像攻击。
ii) Bob can attack the hash. This attack requires a successful collision resistance attack. Unlike case (b), there is nothing that Alice can do to upgrade the attack.
ii）Bob可以攻击散列。此攻击需要成功的抗碰撞攻击。与案例（b）不同，Alice无法升级攻击。
iii) Mallory can attack the hash. This requires a successful preimage attack if the content is unavailable to Mallory and a successful second preimage attack if the content is available to Mallory.
iii）Mallory可以攻击哈希。如果内容对Mallory不可用，则需要成功的前图像攻击；如果内容对Mallory可用，则需要成功的第二次前图像攻击。
2) Hash of signed attributes (i.e., the complete Distinguished Encoding Rules (DER) encoding of the SignedAttrs value contained in the signedAttrs field, as per 5.4 of [CMS]).
2) 签名属性的散列（即，根据[CMS]第5.4条，SignedAttrs字段中包含的SignedAttrs值的完整可分辨编码规则（DER）编码）。
There is a difference between hashing the body and hashing the SignedAttrs value in that one should not accept a sequence of attributes to be signed from a third party. In fact, one should not accept attributes to be included in the signed attributes list from a third party. The attributes are about the signature you are applying and not about the body. If there is meta-information that needs to be attached to the body by a third party, then they need to provide their own signature and you need to add a countersignature. (Note: The fact that the signature is to be used as a countersignature is a piece of information that should be accepted, but it does not directly provide an attribute that is inserted in the signed attribute list.)
散列正文和散列SignedAttrs值之间的区别在于，不应接受要从第三方签名的属性序列。事实上，不应该接受来自第三方的属性包含在签名属性列表中。这些属性与应用的签名有关，而与主体无关。如果有需要由第三方附加到正文的元信息，则他们需要提供自己的签名，并且您需要添加一个会签。（注意：签名用作会签这一事实是一条应被接受的信息，但它不直接提供插入已签名属性列表中的属性。）
a) Alice can attack the hash. This requires a successful collision resistance attack.
a) 爱丽丝可以攻击散列。这需要成功的抗碰撞攻击。
b) Mallory can attack the hash. This requires a successful second preimage resistance attack.
b) 马洛里可以攻击散列。这需要成功的第二次前映像抵抗攻击。
c) Bob can attack the hash and Bob controls the value of the message digest attribute used. This case is analogous to the current attacks [ATTACK]. Bob can attack the hash value generated by Alice based on a prediction of the signed attributes and the hash algorithm Alice will be using to create the signature. If Bob successfully predicts these items, the attack requires a successful collision resistance attack. (It is expected that if Alice uses a keyed hashing function as part of the signature, this attack will be more difficult as Bob would have a harder time prediction the key value.)
c) Bob可以攻击哈希，Bob控制所用消息摘要属性的值。此案例类似于当前的攻击[攻击]。Bob可以根据签名属性的预测攻击Alice生成的哈希值，Alice将使用哈希算法创建签名。如果Bob成功预测这些项目，则攻击需要成功的抗碰撞攻击。（预计如果Alice将密钥散列函数用作签名的一部分，这种攻击将更加困难，因为Bob很难预测密钥值。）
It should be noted that both of these attacks are considered to be more difficult than the attack on the body since more structure is designed into the data to be hashed than is frequently found in the body and the data is shorter in length than that of the body.
应该注意的是，这两种攻击都被认为比对主体的攻击更困难，因为要散列的数据设计的结构比主体中经常发现的要多，并且数据的长度比主体的长度短。
The successful prediction of the signing-time attribute is expected to be more difficult than with certificates as the time would not generally be rounded. Time stamp services can make this more unpredictable by using a random delay before issuing the signature.
由于时间通常不会四舍五入，因此成功预测签名时间属性预计比使用证书更困难。时间戳服务通过在发出签名之前使用随机延迟，使这一点更加不可预测。
Allowing a third party to provide a hash value could potentially make an attack simpler when keyed hash functions are used since there is more data than can be modified without changing the overall structure of the signed attribute structure.
允许第三方提供散列值可能会使使用键控散列函数时的攻击更简单，因为在不改变签名属性结构的总体结构的情况下，数据量超过了可以修改的数据量。
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Jim Schaad Soaring Hawk Consulting
吉姆·沙德·霍克咨询公司
EMail: jimsch@exmsft.com
EMail: jimsch@exmsft.com