Network Working Group R. Housley
Request for Comments: 5652 Vigil Security
Obsoletes: 3852 September 2009
Category: Standards Track
Network Working Group R. Housley
Request for Comments: 5652 Vigil Security
Obsoletes: 3852 September 2009
Category: Standards Track
Cryptographic Message Syntax (CMS)
加密消息语法（CMS）
Abstract
摘要
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
本文档描述了加密消息语法（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 and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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. Evolution of the CMS .......................................4
1.1.1. Changes Since PKCS #7 Version 1.5 ...................4
1.1.2. Changes Since RFC 2630 ..............................4
1.1.3. Changes Since RFC 3369 ..............................5
1.1.4. Changes Since RFC 3852 ..............................5
1.2. Terminology ................................................5
1.3. Version Numbers ............................................6
2. General Overview ................................................6
3. General Syntax ..................................................7
4. Data Content Type ...............................................7
5. Signed-data Content Type ........................................8
5.1. SignedData Type ............................................9
5.2. EncapsulatedContentInfo Type ..............................11
5.2.1. Compatibility with PKCS #7 .........................12
5.3. SignerInfo Type ...........................................13
5.4. Message Digest Calculation Process ........................16
5.5. Signature Generation Process ..............................16
5.6. Signature Verification Process ............................17
6. Enveloped-Data Content Type ....................................17
6.1. EnvelopedData Type ........................................18
6.2. RecipientInfo Type ........................................21
6.2.1. KeyTransRecipientInfo Type .........................22
6.2.2. KeyAgreeRecipientInfo Type .........................23
6.2.3. KEKRecipientInfo Type ..............................25
6.2.4. PasswordRecipientInfo Type .........................26
6.2.5. OtherRecipientInfo Type ............................27
6.3. Content-encryption Process ................................27
6.4. Key-Encryption Process ....................................28
7. Digested-Data Content Type .....................................28
8. Encrypted-Data Content Type ....................................29
9. Authenticated-Data Content Type ................................30
9.1. AuthenticatedData Type ....................................31
9.2. MAC Generation ............................................33
9.3. MAC Verification ..........................................34
10. Useful Types ..................................................34
10.1. Algorithm Identifier Types ...............................35
10.1.1. DigestAlgorithmIdentifier .........................35
10.1.2. SignatureAlgorithmIdentifier ......................35
10.1.3. KeyEncryptionAlgorithmIdentifier ..................35
10.1.4. ContentEncryptionAlgorithmIdentifier ..............36
10.1.5. MessageAuthenticationCodeAlgorithm ................36
10.1.6. KeyDerivationAlgorithmIdentifier ..................36
10.2. Other Useful Types .......................................36
10.2.1. RevocationInfoChoices .............................36
10.2.2. CertificateChoices ................................37
1. Introduction ....................................................3
1.1. Evolution of the CMS .......................................4
1.1.1. Changes Since PKCS #7 Version 1.5 ...................4
1.1.2. Changes Since RFC 2630 ..............................4
1.1.3. Changes Since RFC 3369 ..............................5
1.1.4. Changes Since RFC 3852 ..............................5
1.2. Terminology ................................................5
1.3. Version Numbers ............................................6
2. General Overview ................................................6
3. General Syntax ..................................................7
4. Data Content Type ...............................................7
5. Signed-data Content Type ........................................8
5.1. SignedData Type ............................................9
5.2. EncapsulatedContentInfo Type ..............................11
5.2.1. Compatibility with PKCS #7 .........................12
5.3. SignerInfo Type ...........................................13
5.4. Message Digest Calculation Process ........................16
5.5. Signature Generation Process ..............................16
5.6. Signature Verification Process ............................17
6. Enveloped-Data Content Type ....................................17
6.1. EnvelopedData Type ........................................18
6.2. RecipientInfo Type ........................................21
6.2.1. KeyTransRecipientInfo Type .........................22
6.2.2. KeyAgreeRecipientInfo Type .........................23
6.2.3. KEKRecipientInfo Type ..............................25
6.2.4. PasswordRecipientInfo Type .........................26
6.2.5. OtherRecipientInfo Type ............................27
6.3. Content-encryption Process ................................27
6.4. Key-Encryption Process ....................................28
7. Digested-Data Content Type .....................................28
8. Encrypted-Data Content Type ....................................29
9. Authenticated-Data Content Type ................................30
9.1. AuthenticatedData Type ....................................31
9.2. MAC Generation ............................................33
9.3. MAC Verification ..........................................34
10. Useful Types ..................................................34
10.1. Algorithm Identifier Types ...............................35
10.1.1. DigestAlgorithmIdentifier .........................35
10.1.2. SignatureAlgorithmIdentifier ......................35
10.1.3. KeyEncryptionAlgorithmIdentifier ..................35
10.1.4. ContentEncryptionAlgorithmIdentifier ..............36
10.1.5. MessageAuthenticationCodeAlgorithm ................36
10.1.6. KeyDerivationAlgorithmIdentifier ..................36
10.2. Other Useful Types .......................................36
10.2.1. RevocationInfoChoices .............................36
10.2.2. CertificateChoices ................................37
10.2.3. CertificateSet ....................................38
10.2.4. IssuerAndSerialNumber .............................38
10.2.5. CMSVersion ........................................39
10.2.6. UserKeyingMaterial ................................39
10.2.7. OtherKeyAttribute .................................39
11. Useful Attributes .............................................39
11.1. Content Type .............................................40
11.2. Message Digest ...........................................40
11.3. Signing Time .............................................41
11.4. Countersignature .........................................42
12. ASN.1 Modules .................................................43
12.1. CMS ASN.1 Module .........................................44
12.2. Version 1 Attribute Certificate ASN.1 Module .............51
13. References ....................................................52
13.1. Normative References .....................................52
13.2. Informative References ...................................53
14. Security Considerations .......................................54
15. Acknowledgments ...............................................56
10.2.3. CertificateSet ....................................38
10.2.4. IssuerAndSerialNumber .............................38
10.2.5. CMSVersion ........................................39
10.2.6. UserKeyingMaterial ................................39
10.2.7. OtherKeyAttribute .................................39
11. Useful Attributes .............................................39
11.1. Content Type .............................................40
11.2. Message Digest ...........................................40
11.3. Signing Time .............................................41
11.4. Countersignature .........................................42
12. ASN.1 Modules .................................................43
12.1. CMS ASN.1 Module .........................................44
12.2. Version 1 Attribute Certificate ASN.1 Module .............51
13. References ....................................................52
13.1. Normative References .....................................52
13.2. Informative References ...................................53
14. Security Considerations .......................................54
15. Acknowledgments ...............................................56
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
本文档描述了加密消息语法（CMS）。此语法用于对任意消息内容进行数字签名、摘要、身份验证或加密。
The CMS describes an encapsulation syntax for data protection. It supports digital signatures and encryption. The syntax allows multiple encapsulations; one encapsulation envelope can be nested inside another. Likewise, one party can digitally sign some previously encapsulated data. It also allows arbitrary attributes, such as signing time, to be signed along with the message content, and it provides for other attributes such as countersignatures to be associated with a signature.
CMS描述了用于数据保护的封装语法。它支持数字签名和加密。语法允许多个封装；一个封装信封可以嵌套在另一个信封中。同样，一方可以对一些先前封装的数据进行数字签名。它还允许将任意属性（如签名时间）与消息内容一起签名，并提供与签名关联的其他属性（如反签名）。
The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [PROFILE].
CMS可以支持各种基于证书的密钥管理体系结构，例如PKIX（使用X.509的公钥基础设施）工作组[PROFILE]定义的体系结构。
The CMS values are generated using ASN.1 [X.208-88], using BER-encoding (Basic Encoding Rules) [X.209-88]. Values are typically represented as octet strings. While many systems are capable of transmitting arbitrary octet strings reliably, it is well known that many electronic mail systems are not. This document does not address mechanisms for encoding octet strings for reliable transmission in such environments.
CMS值是使用ASN.1[X.208-88]和BER编码（基本编码规则）[X.209-88]生成的。值通常表示为八位字节字符串。虽然许多系统能够可靠地传输任意八位字节字符串，但众所周知，许多电子邮件系统不能。本文件不涉及八位字节字符串编码机制，以便在此类环境中可靠传输。
The CMS is derived from PKCS #7 version 1.5, which is documented in RFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the IETF; it was originally published as an RSA Laboratories Technical Note in November 1993. Since that time, the IETF has taken responsibility for the development and maintenance of the CMS. Today, several important IETF Standards-Track protocols make use of the CMS.
CMS源于PKCS#7版本1.5，该版本记录在RFC 2315[PKCS#7]中。PKCS#7版本1.5是在IETF之外开发的；它最初于1993年11月作为RSA Laboratories技术说明发布。从那时起，IETF负责CMS的开发和维护。今天，一些重要的IETF标准跟踪协议使用CMS。
This section describes that changes that the IETF has made to the CMS in each of the published versions.
本节描述IETF在每个发布版本中对CMS所做的更改。
RFC 2630 [CMS1] was the first version of the CMS on the IETF Standards Track. Wherever possible, backward compatibility with PKCS #7 version 1.5 is preserved; however, changes were made to accommodate version 1 attribute certificate transfer and to support algorithm-independent key management. PKCS #7 version 1.5 included support only for key transport. RFC 2630 adds support for key agreement and previously distributed symmetric key-encryption key techniques.
RFC 2630[CMS1]是IETF标准轨道上CMS的第一个版本。尽可能保留与PKCS#7 1.5版的向后兼容性；但是，进行了更改以适应版本1属性证书传输并支持独立于算法的密钥管理。PKCS#7 1.5版仅支持密钥传输。RFC2630增加了对密钥协商和以前分布式对称密钥加密技术的支持。
RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. Password-based key management is included in the CMS specification, and an extension mechanism to support new key management schemes without further changes to the CMS is specified. Backward compatibility with RFC 2630 and RFC 3211 is preserved; however, version 2 attribute certificate transfer is added, and the use of version 1 attribute certificates is deprecated.
RFC 3369[CMS2]淘汰了RFC 2630[CMS1]和RFC 3211[PWRI]。基于密码的密钥管理包含在CMS规范中，并指定了一种扩展机制，以支持新的密钥管理方案，而无需对CMS进行进一步更改。保留了与RFC 2630和RFC 3211的向后兼容性；但是，添加了版本2属性证书传输，不推荐使用版本1属性证书。
Secure/Multipurpose Internet Mail Extensions (S/MIME) v2 signatures [MSG2], which are based on PKCS #7 version 1.5, are compatible with S/MIME v3 signatures [MSG3]and S/MIME v3.1 signatures [MSG3.1]. However, there are some subtle compatibility issues with signatures based on PKCS #7 version 1.5. These issues are discussed in Section 5.2.1. These issues remain with the current version of the CMS.
基于PKCS#7版本1.5的安全/多用途Internet邮件扩展（S/MIME）v2签名[MSG2]与S/MIME v3签名[MSG3]和S/MIME v3.1签名[MSG3.1]兼容。但是，基于PKCS#7 1.5版的签名存在一些微妙的兼容性问题。第5.2.1节讨论了这些问题。这些问题仍然存在于CMS的当前版本中。
Specific cryptographic algorithms are not discussed in this document, but they were discussed in RFC 2630. The discussion of specific cryptographic algorithms has been moved to a separate document [CMSALG]. Separation of the protocol and algorithm specifications allows the IETF to update each document independently. This specification does not require the implementation of any particular
本文档中未讨论特定的加密算法，但RFC 2630中讨论了这些算法。关于特定密码算法的讨论已移至单独的文件[CMSALG]。协议和算法规范的分离允许IETF独立更新每个文档。本规范不要求执行任何特定的
algorithms. Rather, protocols that rely on the CMS are expected to choose appropriate algorithms for their environment. The algorithms may be selected from [CMSALG] or elsewhere.
算法。相反，依赖CMS的协议应该为其环境选择合适的算法。可从[CMSALG]或其他地方选择算法。
RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in the previous section, RFC 3369 introduced an extension mechanism to support new key management schemes without further changes to the CMS. RFC 3852 introduces a similar extension mechanism to support additional certificate formats and revocation status information formats without further changes to the CMS. These extensions are primarily documented in Sections 10.2.1 and 10.2.2. Backward compatibility with earlier versions of the CMS is preserved.
RFC 3852[CMS3]淘汰了RFC 3369[CMS2]。如前一节所述，RFC 3369引入了一种扩展机制，以支持新的密钥管理方案，而无需对CMS进行进一步更改。RFC3852引入了类似的扩展机制，以支持附加的证书格式和吊销状态信息格式，而无需对CMS进行进一步更改。这些扩展主要记录在第10.2.1节和第10.2.2节中。保留与CMS早期版本的向后兼容性。
The use of version numbers is described in Section 1.3.
第1.3节介绍了版本号的使用。
Since the publication of RFC 3369, a few errata have been noted. These errata are posted on the RFC Editor web site. These errors have been corrected in this document.
自RFC 3369出版以来，已注意到一些勘误表。这些勘误表发布在RFC编辑器网站上。这些错误已在本文档中更正。
The text in Section 11.4 that describes the counter signature unsigned attribute is clarified. Hopefully, the revised text is clearer about the portion of the SignerInfo signature that is covered by a countersignature.
第11.4节中描述计数器签名未签名属性的文本已澄清。希望修订后的文本能更清楚地说明会签所涵盖的签名信息部分。
This document obsoletes RFC 3852 [CMS3]. The primary reason for the publication of this document is to advance the CMS along the standards maturity ladder.
本文件淘汰了RFC 3852[CMS3]。发布本文件的主要原因是沿着标准成熟度阶梯推进CMS。
This document includes the clarifications that were originally published in RFC 4853 [CMSMSIG] regarding the proper handling of the SignedData protected content type when more than one digital signature is present.
本文件包括最初在RFC 4853[CMSMSIG]中发布的关于在存在多个数字签名时正确处理受签名数据保护的内容类型的澄清。
Since the publication of RFC 3852, a few errata have been noted. These errata are posted on the RFC Editor web site. These errors have been corrected in this document.
自RFC 3852出版以来，已注意到一些勘误表。这些勘误表发布在RFC编辑器网站上。这些错误已在本文档中更正。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS].
在本文件中，关键字“必须”、“不得”、“必需”、“应当”、“不应当”、“建议”、“可以”和“可选”应按照[STDOWORDS]中的说明进行解释。
Each of the major data structures includes a version number as the first item in the data structure. The version numbers are intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode error occurs, then the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.
每个主要数据结构都包含一个版本号，作为数据结构中的第一项。版本号旨在避免ASN.1解码错误。一些实现在尝试解码之前不检查版本号，如果出现解码错误，则作为错误处理例程的一部分检查版本号。这是一个合理的方法；它将错误处理置于快速路径之外。当发送方使用了不正确的版本号时，这种方法也是可以原谅的。
Most of the initial version numbers were assigned in PKCS #7 version 1.5. Others were assigned when the structure was initially created. Whenever a structure is updated, a higher version number is assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used.
大多数初始版本号在PKCS#7版本1.5中分配。在最初创建结构时，已指定其他对象。每当更新结构时，都会分配更高的版本号。但是，为了确保最大的互操作性，只有在使用新语法功能时才使用更高的版本号。也就是说，使用支持生成语法的最低版本号。
The CMS is general enough to support many different content types. This document defines one protection content, ContentInfo. ContentInfo encapsulates a single identified content type, and the identified type may provide further encapsulation. This document defines six content types: data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data. Additional content types can be defined outside this document.
CMS足够通用，可以支持多种不同的内容类型。本文档定义了一个保护内容ContentInfo。ContentInfo封装单个已标识的内容类型，已标识的类型可以提供进一步的封装。本文档定义了六种内容类型：数据、签名数据、信封数据、摘要数据、加密数据和认证数据。可以在此文档之外定义其他内容类型。
An implementation that conforms to this specification MUST implement the protection content, ContentInfo, and MUST implement the data, signed-data, and enveloped-data content types. The other content types MAY be implemented.
符合此规范的实现必须实现保护内容、ContentInfo，并且必须实现数据、签名数据和封装数据内容类型。可以实现其他内容类型。
As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER) encoding. Single-pass operation is especially helpful if content is large, stored on tapes, or is "piped" from another process. Single-pass operation has one significant drawback: it is difficult to perform encode operations using the Distinguished Encoding Rules (DER) [X.509-88] encoding in a single pass since the lengths of the various components may not be known in advance. However, signed attributes within the signed-data content type and authenticated attributes within the authenticated-data content type need to be transmitted in DER form to ensure that recipients can verify a content that contains one or more unrecognized attributes. Signed attributes and authenticated attributes are the only data types used in the CMS that require DER encoding.
作为一般设计理念，每种内容类型都允许使用不定长基本编码规则（BER）编码进行单遍处理。如果内容较大、存储在磁带上或从另一个进程“管道”传输，则单程操作尤其有用。单遍操作有一个显著的缺点：在单遍中使用可分辨编码规则（DER）[X.509-88]编码很难执行编码操作，因为各种组件的长度可能事先未知。但是，需要以DER格式传输已签名数据内容类型中的已签名属性和已认证数据内容类型中的已认证属性，以确保收件人可以验证包含一个或多个未识别属性的内容。签名属性和认证属性是CMS中唯一需要DER编码的数据类型。
The following object identifier identifies the content information type:
以下对象标识符标识内容信息类型：
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
The CMS associates a content type identifier with a content. The syntax MUST have ASN.1 type ContentInfo:
CMS将内容类型标识符与内容相关联。语法必须具有ASN.1类型ContentInfo:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The fields of ContentInfo have the following meanings:
ContentInfo的字段具有以下含义：
contentType indicates the type of the associated content. It is an object identifier; it is a unique string of integers assigned by an authority that defines the content type.
contentType指示关联内容的类型。它是一个对象标识符；它是由定义内容类型的机构分配的唯一整数字符串。
content is the associated content. The type of content can be determined uniquely by contentType. Content types for data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data are defined in this document. If additional content types are defined in other documents, the ASN.1 type defined SHOULD NOT be a CHOICE type.
内容是关联的内容。内容的类型可以由contentType唯一确定。本文档定义了数据、签名数据、信封数据、摘要数据、加密数据和认证数据的内容类型。如果在其他文档中定义了其他内容类型，则定义的ASN.1类型不应是选项类型。
The following object identifier identifies the data content type:
以下对象标识符标识数据内容类型：
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure (although they could have their own ASN.1 definition or other structure).
数据内容类型旨在指任意八位字符串，如ASCII文本文件；解释权留给应用程序。这样的字符串不需要任何内部结构（尽管它们可以有自己的ASN.1定义或其他结构）。
S/MIME uses id-data to identify MIME-encoded content. The use of this content identifier is specified in RFC 2311 for S/MIME v2 [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 [MSG3.1].
S/MIME使用id数据来标识MIME编码的内容。该内容标识符的使用在RFC 2311中为S/MIME v2[MSG2]指定，RFC 2633中为S/MIME v3[MSG3]指定，RFC 3851中为S/MIME v3.1[MSG3.1]指定。
The data content type is generally encapsulated in the signed-data, enveloped-data, digested-data, encrypted-data, or authenticated-data content type.
数据内容类型通常封装在签名数据、信封数据、摘要数据、加密数据或认证数据内容类型中。
The signed-data content type consists of a content of any type and zero or more signature values. Any number of signers in parallel can sign any type of content.
签名数据内容类型由任何类型的内容和零个或多个签名值组成。任意数量的签名者可以并行签名任何类型的内容。
The typical application of the signed-data content type represents one signer's digital signature on content of the data content type. Another typical application disseminates certificates and certificate revocation lists (CRLs).
签名数据内容类型的典型应用程序表示一个签名者对数据内容类型内容的数字签名。另一个典型的应用程序传播证书和证书撤销列表（CRL）。
The process by which signed-data is constructed involves the following steps:
构造签名数据的过程包括以下步骤：
1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information are digested with the signer's message digest algorithm (see Section 5.4), and the result becomes the "message digest."
1. 对于每个签名者，使用特定于签名者的消息摘要算法对内容计算消息摘要或哈希值。如果签名者对内容以外的任何信息进行签名，则使用签名者的消息摘要算法（见第5.4节）对内容和其他信息的消息摘要进行摘要处理，结果成为“消息摘要”
2. For each signer, the message digest is digitally signed using the signer's private key.
2. 对于每个签名者，使用签名者的私钥对消息摘要进行数字签名。
3. For each signer, the signature value and other signer-specific information are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and those not corresponding to any signer, are collected in this step.
3. 对于每个签名者，签名值和其他特定于签名者的信息被收集到SignerInfo值中，如第5.3节所定义。在此步骤中，将收集每个签名者的证书和CRL，以及与任何签名者都不对应的证书和CRL。
4. The message digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1.
4. 所有签名者的消息摘要算法和所有签名者的SignerInfo值与内容一起收集到SignedData值中，如第5.1节所定义。
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 in one of two ways. It can be referenced by an issuer distinguished name along with an issuer-specific serial number to uniquely identify the certificate that contains the public key. Alternatively, it can be referenced by a subject key identifier, which accommodates both certified and uncertified public keys. While not required, the signer's certificate can be included in the SignedData certificates field.
收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。签名者的公钥以两种方式之一引用。它可以由颁发者可分辨名称和特定于颁发者的序列号引用，以唯一标识包含公钥的证书。或者，它可以由主体密钥标识符引用，主体密钥标识符容纳认证和未认证的公钥。虽然不是必需的，但签名者的证书可以包含在SignedData certificates字段中。
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 Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. This allows recipients to verify the signature associated with one algorithm or the other.
当存在多个签名时，与给定签名人关联的一个签名的成功验证通常被该签名人视为成功签名。但是，有些应用程序环境需要其他规则。对每个签名者使用一个有效签名以外的规则的应用程序必须指定这些规则。此外，如果签名者标识符的简单匹配不足以确定签名是否由同一签名者生成，则应用程序规范必须描述如何确定哪些签名由同一签名者生成。支持不同的收件人社区是签名者选择包含多个签名的主要原因。例如，签名数据内容类型可能包括使用RSA签名算法和椭圆曲线数字签名算法（ECDSA）签名算法生成的签名。这允许收件人验证与一种算法或另一种算法关联的签名。
This section is divided into six parts. The first part describes the top-level type SignedData, the second part describes EncapsulatedContentInfo, the third part describes the per-signer information type SignerInfo, and the fourth, fifth, and sixth parts describe the message digest calculation, signature generation, and signature verification processes, respectively.
本节分为六个部分。第一部分描述了顶级类型SignedData，第二部分描述了封装的ContentInfo，第三部分描述了每签名者信息类型SignerInfo，第四、第五和第六部分分别描述了消息摘要计算、签名生成和签名验证过程。
The following object identifier identifies the signed-data content type:
以下对象标识符标识签名数据内容类型：
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
The signed-data content type shall have ASN.1 type SignedData:
签名数据内容类型应具有ASN.1类型签名数据：
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings:
SignedData类型的字段具有以下含义：
version is the syntax version number. The appropriate value depends on certificates, eContentType, and SignerInfo. The version MUST be assigned as follows:
version是语法版本号。适当的值取决于证书、eContentType和SignerinInfo。必须按如下方式分配版本：
IF ((certificates is present) AND (any certificates with a type of other are present)) OR ((crls is present) AND (any crls with a type of other are present)) THEN version MUST be 5 ELSE IF (certificates is present) AND (any version 2 attribute certificates are present) THEN version MUST be 4 ELSE IF ((certificates is present) AND (any version 1 attribute certificates are present)) OR (any SignerInfo structures are version 3) OR (encapContentInfo eContentType is other than id-data) THEN version MUST be 3 ELSE version MUST be 1
如果（（证书存在）和（任何其他类型的证书存在））或（（CRL存在）和（任何其他类型的CRL存在）），则版本必须为5，否则如果（证书存在）和（任何版本2属性证书存在），则版本必须为4，否则如果（（证书存在）和（存在任何版本1属性证书）或（任何SignerInfo结构都是版本3）或（encapContentInfo EcontType不是id数据），则版本必须为3，否则版本必须为1
digestAlgorithms is a collection of message digest algorithm identifiers. There MAY be any number of elements in the collection, including zero. Each element identifies the message digest algorithm, along with any associated parameters, used by one or more signer. The collection is intended to list the message digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. The message digesting process is described in Section 5.4.
digestAlgorithms是消息摘要算法标识符的集合。集合中可能有任意数量的元素，包括零。每个元素标识一个或多个签名者使用的消息摘要算法以及任何相关参数。该集合旨在以任何顺序列出所有签名者所使用的消息摘要算法，以便于一次性签名验证。实现可能无法验证使用此集合中未包含的摘要算法的签名。第5.4节描述了消息摘要处理过程。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself. Details of the EncapsulatedContentInfo type are discussed in Section 5.2.
encapContentInfo是已签名的内容，由内容类型标识符和内容本身组成。第5.2节讨论了封装的ContentInfo类型的详细信息。
certificates is a collection of certificates. It is intended that the set of certificates be sufficient to contain certification paths from a recognized "root" or "top-level certification authority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may be certificates sufficient to contain certification paths from two or more independent top-level certification authorities. There may also be fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessary
证书是证书的集合。这组证书足以包含从公认的“根”或“顶级证书颁发机构”到signerInfos字段中所有签名者的证书路径。证书可能比需要的多，并且可能有足够的证书包含来自两个或多个独立的顶级证书颁发机构的证书路径。如果预期接收人有获得必要证书的替代方法，则证书数量也可能少于必要数量
certificates (e.g., from a previous set of certificates). The signer's certificate MAY be included. The use of version 1 attribute certificates is strongly discouraged.
证书（例如，来自以前的一组证书）。可包括签名人的证书。强烈反对使用版本1属性证书。
crls is a collection of revocation status information. It is intended that the collection contain information sufficient to determine whether the certificates in the certificates field are valid, but such correspondence is not necessary. Certificate revocation lists (CRLs) are the primary source of revocation status information. There MAY be more CRLs than necessary, and there MAY also be fewer CRLs than necessary.
crls是吊销状态信息的集合。该集合包含足以确定证书字段中的证书是否有效的信息，但不需要这样的通信。证书吊销列表（CRL）是吊销状态信息的主要来源。CRL可能比需要的多，也可能比需要的少。
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.
signerInfos是每个签名者信息的集合。集合中可能有任意数量的元素，包括零。当集合表示多个签名时，来自给定签名者的一个签名的成功验证应由该签名者视为成功签名。但是，有些应用程序环境需要其他规则。第5.3节讨论了SignerInfo类型的详细信息。由于每个签名者都可以使用不同的数字签名技术，而且未来的规范可能会更新语法，因此所有实现都必须优雅地处理未实现的SignerInfo版本。此外，由于所有实现都不支持所有可能的签名算法，因此所有实现在遇到未实现的签名算法时都必须优雅地处理它们。
The content is represented in the type EncapsulatedContentInfo:
内容以封装的ContentInfo类型表示：
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The fields of type EncapsulatedContentInfo have the following meanings:
封装ContentInfo类型的字段具有以下含义：
eContentType is an object identifier. The object identifier uniquely specifies the content type.
eContentType是一个对象标识符。对象标识符唯一地指定内容类型。
eContent is the content itself, carried as an octet string. The eContent need not be DER encoded.
eContent是内容本身，作为八位字节字符串携带。eContent不需要进行DER编码。
The optional omission of the eContent within the EncapsulatedContentInfo field makes it possible to construct "external signatures". In the case of external signatures, the content being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present.
在封装的ContentInfo字段中可选地省略eContent，这使得构造“外部签名”成为可能。对于外部签名，已签名数据内容类型中包含的封装ContentInfo值中不包含正在签名的内容。如果封装的ContentInfo中没有eContent值，则会计算signatureValue并分配eContentType，就像存在eContent值一样。
In the degenerate case where there are no signers, the EncapsulatedContentInfo value being "signed" is irrelevant. In this case, the content type within the EncapsulatedContentInfo value being "signed" MUST be id-data (as defined in Section 4), and the content field of the EncapsulatedContentInfo value MUST be omitted.
在没有签名者的退化情况下，被“签名”的封装ContentInfo值是不相关的。在这种情况下，被“签名”的封装ContentInfo值内的内容类型必须是id数据（如第4节所定义），并且必须省略封装ContentInfo值的内容字段。
This section contains a word of warning to implementers that wish to support both the CMS and PKCS #7 [PKCS#7] SignedData content types. Both the CMS and PKCS #7 identify the type of the encapsulated content with an object identifier, but the ASN.1 type of the content itself is variable in PKCS #7 SignedData content type.
本节向希望同时支持CMS和PKCS#7[PKCS#7]SignedData内容类型的实施者发出警告。CMS和PKCS#7都使用对象标识符标识封装内容的类型，但内容的ASN.1类型本身在PKCS#7 SignedData content type中是可变的。
PKCS #7 defines content as:
PKCS#7将内容定义为：
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
内容[0]由contentType定义的任何显式可选
The CMS defines eContent as:
CMS将eContent定义为：
eContent [0] EXPLICIT OCTET STRING OPTIONAL
eContent[0]显式八位字节字符串可选
The CMS definition is much easier to use in most applications, and it is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed messages using the CMS and PKCS #7 are compatible because identical signed message formats are specified in RFC 2311 for S/MIME v2 [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 [MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type (that is, an OCTET STRING) carried in the SignedData contentInfo content ANY field, and S/MIME v3 carries the MIME content in the SignedData encapContentInfo eContent OCTET STRING. Therefore, in S/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in an OCTET STRING and the message digest is computed over the identical portions of the content. That is, the message digest is computed over the octets comprising the value of the OCTET STRING, neither the tag nor length octets are included.
CMS定义在大多数应用程序中更易于使用，并且与S/MIME v2和S/MIME v3兼容。使用CMS和PKCS#7的S/MIME签名消息是兼容的，因为RFC 2311为S/MIME v2[MSG2]指定了相同的签名消息格式，RFC 2633为S/MIME v3[MSG3]，RFC 3851为S/MIME v3.1[MSG3.1]指定了相同的签名消息格式。S/MIME v2将MIME内容封装在SignedData contentInfo内容任意字段中携带的数据类型（即八位字节字符串）中，S/MIME v3将MIME内容封装在SignedData encapContentInfo eContent八位字节字符串中。因此，在S/MIME v2、S/MIME v3和S/MIME v3.1中，MIME内容放在八位字节字符串中，消息摘要在内容的相同部分上计算。也就是说，消息摘要是在包含八位字节字符串值的八位字节上计算的，不包括标记和长度八位字节。
There are incompatibilities between the CMS and PKCS #7 SignedData types when the encapsulated content is not formatted using the Data type. For example, when an RFC 2634 signed receipt [ESS] is encapsulated in the CMS SignedData type, then the Receipt SEQUENCE is encoded in the SignedData encapContentInfo eContent OCTET STRING and the message digest is computed using the entire Receipt SEQUENCE encoding (including tag, length and value octets). However, if an RFC 2634 signed receipt is encapsulated in the PKCS #7 SignedData type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET STRING). Therefore, the message digest is computed using only the value octets of the Receipt SEQUENCE encoding.
当封装内容未使用数据类型格式化时，CMS和PKCS#7 SignedData类型之间存在不兼容。例如，当RFC 2634签名回执[ESS]封装在CMS SignedData类型中时，回执序列编码在SignedData encapContentInfo eContent八位字节字符串中，并且使用整个回执序列编码（包括标记、长度和值八位字节）计算消息摘要。但是，如果RFC 2634签名回执封装在PKCS#7 SignedData类型中，则回执序列在SignedData contentInfo content ANY字段中按顺序编码[X.509-88]（序列，而不是八位字节字符串）。因此，仅使用接收序列编码的值八位字节来计算消息摘要。
The following strategy can be used to achieve backward compatibility with PKCS #7 when processing SignedData content types. If the implementation is unable to ASN.1 decode the SignedData type using the CMS SignedData encapContentInfo eContent OCTET STRING syntax, then the implementation MAY attempt to decode the SignedData type using the PKCS #7 SignedData contentInfo content ANY syntax and compute the message digest accordingly.
在处理SignedData内容类型时，可以使用以下策略实现与PKCS#7的向后兼容性。如果实现无法使用CMS SignedData encapContentInfo eContent八进制字符串语法对SignedData类型进行ASN.1解码，则实现可能会尝试使用PKCS#7 SignedData contentInfo任何语法对SignedData类型进行解码，并相应地计算消息摘要。
The following strategy can be used to achieve backward compatibility with PKCS #7 when creating a SignedData content type in which the encapsulated content is not formatted using the Data type. Implementations MAY examine the value of the eContentType, and then adjust the expected DER encoding of eContent based on the object identifier value. For example, to support Microsoft Authenticode [MSAC], the following information MAY be included:
在创建SignedData内容类型时，可以使用以下策略实现与PKCS#7的向后兼容性，其中封装的内容未使用数据类型进行格式化。实现可以检查eContentType的值，然后根据对象标识符值调整eContent的预期DER编码。例如，为了支持Microsoft Authenticode[MSAC]，可能会包括以下信息：
eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
eContentType对象标识符设置为{1 3 6 1 4 1 311 2 1 4}
eContent contains DER-encoded Authenticode signing information
eContent包含DER编码的身份验证码签名信息
Per-signer information is represented in the type SignerInfo:
每个签名者的信息以SignerinInfo类型表示：
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
AttributeValue ::= ANY
SignatureValue ::= OCTET STRING
SignatureValue ::= OCTET STRING
The fields of type SignerInfo have the following meanings:
SignerInfo类型的字段具有以下含义：
version is the syntax version number. If the SignerIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 1. If the SignerIdentifier is subjectKeyIdentifier, then the version MUST be 3.
version是语法版本号。如果SignerIdentifier是选择issuerAndSerialNumber，则版本必须为1。如果SignerIdentifier是subjectKeyIdentifier，则版本必须为3。
sid specifies the signer's certificate (and thereby the signer's public key). The signer's public key is needed by the recipient to verify the signature. SignerIdentifier provides two alternatives for specifying the signer's public key. The issuerAndSerialNumber alternative identifies the signer's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier identifies the signer's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. Implementations MUST support the reception of the issuerAndSerialNumber and subjectKeyIdentifier forms of SignerIdentifier. When generating a SignerIdentifier, implementations MAY support one of the forms (either issuerAndSerialNumber or subjectKeyIdentifier) and always use it, or implementations MAY arbitrarily mix the two forms. However, subjectKeyIdentifier MUST be used to refer to a public key contained in a non-X.509 certificate.
sid指定签名者的证书（从而指定签名者的公钥）。收件人需要签名人的公钥来验证签名。SignerIdentifier为指定签名者的公钥提供了两种选择。issuerAndSerialNumber替代方案通过发行人的可分辨名称和证书序列号识别签名人的证书；subjectKeyIdentifier通过密钥标识符标识签名者的证书。引用X.509证书时，密钥标识符与X.509 subjectKeyIdentifier扩展值匹配。当引用其他证书格式时，指定证书格式及其在CMS中的使用的文档必须包括有关将密钥标识符匹配到相应证书字段的详细信息。实现必须支持接收SignerIdentifier的issuerAndSerialNumber和subjectKeyIdentifier表单。生成SignerIdentifier时，实现可能支持其中一种形式（issuerAndSerialNumber或subjectKeyIdentifier）并始终使用它，或者实现可能任意混合使用这两种形式。但是，subjectKeyIdentifier必须用于引用非X.509证书中包含的公钥。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the signer. The message digest is computed on either the content being signed or the content
digestAlgorithm标识签名者使用的消息摘要算法和任何相关参数。消息摘要是根据要签名的内容或内容计算的
together with the signed attributes using the process described in Section 5.4. The message digest algorithm SHOULD be among those listed in the digestAlgorithms field of the associated SignerData. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in the SignedData digestAlgorithms set.
以及使用第5.4节中描述的过程的签名属性。消息摘要算法应在相关SignerData的digestAlgorithms字段中列出。实现可能无法验证使用未包含在SignedData digestAlgorithms集中的摘要算法的签名。
signedAttrs is a collection of attributes that are signed. The field is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data. SignedAttributes MUST be DER encoded, even if the rest of the structure is BER encoded. Useful attribute types, such as signing time, are defined in Section 11. If the field is present, it MUST contain, at a minimum, the following two attributes:
signedAttrs是已签名属性的集合。该字段是可选的，但如果要签名的En封装ContentInfo值的内容类型不是id数据，则该字段必须存在。签名属性必须是DER编码的，即使结构的其余部分是BER编码的。第11节定义了有用的属性类型，如签名时间。如果存在该字段，则该字段必须至少包含以下两个属性：
A content-type attribute having as its value the content type of the EncapsulatedContentInfo value being signed. Section 11.1 defines the content-type attribute. However, the content-type attribute MUST NOT be used as part of a countersignature unsigned attribute as defined in Section 11.4.
一种内容类型属性，其值为要签名的封装ContentInfo值的内容类型。第11.1节定义了内容类型属性。但是，内容类型属性不得用作第11.4节中定义的副署无符号属性的一部分。
A message-digest attribute, having as its value the message digest of the content. Section 11.2 defines the message-digest attribute.
消息摘要属性，其值为内容的消息摘要。第11.2节定义了消息摘要属性。
signatureAlgorithm identifies the signature algorithm, and any associated parameters, used by the signer to generate the digital signature.
signatureAlgorithm标识签名者用于生成数字签名的签名算法和任何相关参数。
signature is the result of digital signature generation, using the message digest and the signer's private key. The details of the signature depend on the signature algorithm employed.
签名是使用消息摘要和签名者的私钥生成数字签名的结果。签名的细节取决于所采用的签名算法。
unsignedAttrs is a collection of attributes that are not signed. The field is optional. Useful attribute types, such as countersignatures, are defined in Section 11.
unsignedAttrs是未签名属性的集合。该字段是可选的。第11节定义了有用的属性类型，如副署。
The fields of type SignedAttribute and UnsignedAttribute have the following meanings:
SignedAttribute和UnsignedAttribute类型的字段具有以下含义：
attrType indicates the type of attribute. It is an object identifier.
attrType指示属性的类型。它是一个对象标识符。
attrValues is a set of values that comprise the attribute. The type of each value in the set can be determined uniquely by attrType. The attrType can impose restrictions on the number of items in the set.
attrValues是组成属性的一组值。集合中每个值的类型可以由attrType唯一确定。attrType可以对集合中的项目数施加限制。
The message digest calculation process computes a message digest on either the content being signed or the content together with the signed attributes. In either case, the initial input to the message digest calculation process is the "value" of the encapsulated content being signed. Specifically, the initial input is the encapContentInfo eContent OCTET STRING to which the signing process is applied. Only the octets comprising the value of the eContent OCTET STRING are input to the message digest algorithm, not the tag or the length octets.
消息摘要计算过程对正在签名的内容或内容以及已签名的属性计算消息摘要。在任何一种情况下，消息摘要计算过程的初始输入都是被签名的封装内容的“值”。具体来说，初始输入是应用签名过程的encapContentInfo eContent八位字符串。只有包含eContent八位元字符串值的八位元被输入到消息摘要算法，而不是标记或长度八位元。
The result of the message digest calculation process depends on whether the signedAttrs field is present. When the field is absent, the result is just the message digest of the content as described above. When the field is present, however, the result is the message digest of the complete DER encoding of the SignedAttrs value contained in the signedAttrs field. Since the SignedAttrs value, when present, must contain the content-type and the message-digest attributes, those values are indirectly included in the result. The content-type attribute MUST NOT be included in a countersignature unsigned attribute as defined in Section 11.4. A separate encoding of the signedAttrs field is performed for message digest calculation. The IMPLICIT [0] tag in the signedAttrs is not used for the DER encoding, rather an EXPLICIT SET OF tag is used. That is, the DER encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] tag, MUST be included in the message digest calculation along with the length and content octets of the SignedAttributes value.
消息摘要计算过程的结果取决于signedAttrs字段是否存在。当字段不存在时，结果就是如上所述的内容的消息摘要。但是，当该字段存在时，结果是SignedAttrs字段中包含的SignedAttrs值的完整DER编码的消息摘要。由于SignedAttrs值（如果存在）必须包含内容类型和消息摘要属性，因此这些值将间接包含在结果中。内容类型属性不得包含在第11.4节中定义的副署无符号属性中。对signedAttrs字段执行单独的编码以进行消息摘要计算。signedAttrs中的隐式[0]标记不用于DER编码，而是使用一组显式标记。也就是说，显式标记集而不是隐式[0]标记的DER编码必须与SignedAttribute值的长度和内容八位字节一起包含在消息摘要计算中。
When the signedAttrs field is absent, only the octets comprising the value of the SignedData encapContentInfo eContent OCTET STRING (e.g., the contents of a file) are input to the message digest calculation. This has the advantage that the length of the content being signed need not be known in advance of the signature generation process.
当signedAttrs字段不存在时，只有包含SignedData encapContentInfo eContent八位字节字符串值的八位字节（例如，文件内容）被输入到消息摘要计算中。这具有这样的优点，即在签名生成过程之前不需要知道被签名的内容的长度。
Although the encapContentInfo eContent OCTET STRING tag and length octets are not included in the message digest calculation, they are protected by other means. The length octets are protected by the nature of the message digest algorithm since it is computationally infeasible to find any two distinct message contents of any length that have the same message digest.
尽管消息摘要计算中不包括encapContentInfo eContent八位字节字符串标记和长度八位字节，但它们通过其他方式受到保护。长度八位字节受消息摘要算法的性质保护，因为在计算上不可能找到具有相同消息摘要的任何长度的任何两个不同消息内容。
The input to the signature generation process includes the result of the message digest calculation process and the signer's private key. The details of the signature generation depend on the signature algorithm employed. The object identifier, along with any
签名生成过程的输入包括消息摘要计算过程的结果和签名者的私钥。签名生成的细节取决于所采用的签名算法。对象标识符，以及任何
parameters, that specifies the signature algorithm employed by the signer is carried in the signatureAlgorithm field. The signature value generated by the signer MUST be encoded as an OCTET STRING and carried in the signature field.
参数，指定签名者使用的签名算法，该参数在signatureAlgorithm字段中携带。签名者生成的签名值必须编码为八位字节字符串，并在签名字段中携带。
The input to the signature verification process includes the result of the message digest calculation process and the signer's public key. The recipient MAY obtain the correct public key for the signer by any means, but the preferred method is from a certificate obtained from the SignedData certificates field. The selection and validation of the signer's public key MAY be based on certification path validation (see [PROFILE]) as well as other external context, but is beyond the scope of this document. The details of the signature verification depend on the signature algorithm employed.
签名验证过程的输入包括消息摘要计算过程的结果和签名者的公钥。接收方可以通过任何方式为签名者获取正确的公钥，但首选方法是从SignedData certificates字段获取证书。签名人公钥的选择和验证可能基于认证路径验证（见[PROFILE]）以及其他外部上下文，但不在本文档范围内。签名验证的细节取决于所采用的签名算法。
The recipient MUST NOT rely on any message digest values computed by the originator. If the SignedData signerInfo includes signedAttributes, then the content message digest MUST be calculated as described in Section 5.4. For the signature to be valid, the message digest value calculated by the recipient MUST be the same as the value of the messageDigest attribute included in the signedAttributes of the SignedData signerInfo.
收件人不得依赖发端人计算的任何邮件摘要值。如果SignedData signerInfo包含SignedAttribute，则必须按照第5.4节所述计算内容消息摘要。要使签名有效，收件人计算的邮件摘要值必须与SignedData signerInfo的SignedAttribute中包含的messageDigest属性的值相同。
If the SignedData signerInfo includes signedAttributes, then the content-type attribute value MUST match the SignedData encapContentInfo eContentType value.
如果SignedData signerInfo包含SignedAttribute，则内容类型属性值必须与SignedData encapContentInfo eContentType值匹配。
The enveloped-data content type consists of an encrypted content of any type and encrypted content-encryption keys for one or more recipients. The combination of the encrypted content and one encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for an arbitrary number of recipients using any of the supported key management techniques for each recipient.
信封数据内容类型包括任何类型的加密内容和一个或多个收件人的加密内容加密密钥。收件人的加密内容和一个加密内容加密密钥的组合是该收件人的“数字信封”。对于任意数量的收件人，可以使用任何支持的密钥管理技术为每个收件人封装任何类型的内容。
The typical application of the enveloped-data content type will represent one or more recipients' digital envelopes on content of the data or signed-data content types.
信封数据内容类型的典型应用将代表一个或多个接收者关于数据内容或签名数据内容类型的数字信封。
Enveloped-data is constructed by the following steps:
通过以下步骤构造包络数据：
1. A content-encryption key for a particular content-encryption algorithm is generated at random.
1. 随机生成特定内容加密算法的内容加密密钥。
2. The content-encryption key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used, but four general techniques are supported:
2. 为每个收件人加密内容加密密钥。此加密的细节取决于使用的密钥管理算法，但支持四种通用技术：
key transport: the content-encryption key is encrypted in the recipient's public key;
密钥传输：内容加密密钥在接收方公钥中加密；
key agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-encryption key is encrypted in the pairwise symmetric key;
密钥协议：使用接收方的公钥和发送方的私钥生成成对对称密钥，然后在成对对称密钥中加密内容加密密钥；
symmetric key-encryption keys: the content-encryption key is encrypted in a previously distributed symmetric key-encryption key; and
对称密钥加密密钥：内容加密密钥在先前分发的对称密钥加密密钥中加密；和
passwords: the content-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.
密码：内容加密密钥在从密码或其他共享密钥值派生的密钥加密密钥中加密。
3. For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2.
3. 对于每个收件人，加密的内容加密密钥和其他收件人特定信息被收集到第6.2节中定义的RecipientInfo值中。
4. The content is encrypted with the content-encryption key. Content encryption may require that the content be padded to a multiple of some block size; see Section 6.3.
4. 使用内容加密密钥对内容进行加密。内容加密可能需要将内容填充到某个块大小的倍数；见第6.3节。
5. The RecipientInfo values for all the recipients are collected together with the encrypted content to form an EnvelopedData value as defined in Section 6.1.
5. 所有收件人的RecipientInfo值与加密内容一起收集，形成第6.1节中定义的信封数据值。
A recipient opens the digital envelope by decrypting one of the encrypted content-encryption keys and then decrypting the encrypted content with the recovered content-encryption key.
收件人通过解密其中一个加密内容加密密钥，然后使用恢复的内容加密密钥解密加密内容来打开数字信封。
This section is divided into four parts. The first part describes the top-level type EnvelopedData, the second part describes the per-recipient information type RecipientInfo, and the third and fourth parts describe the content-encryption and key-encryption processes.
本节分为四个部分。第一部分描述顶级类型EnvelopedData，第二部分描述每个收件人信息类型RecipientInfo，第三和第四部分描述内容加密和密钥加密过程。
The following object identifier identifies the enveloped-data content type:
以下对象标识符标识封装的数据内容类型：
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
The enveloped-data content type shall have ASN.1 type EnvelopedData:
封装数据内容类型应具有ASN.1类型的封装数据：
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type EnvelopedData have the following meanings:
EnvelopedData类型的字段具有以下含义：
version is the syntax version number. The appropriate value depends on originatorInfo, RecipientInfo, and unprotectedAttrs. The version MUST be assigned as follows:
version是语法版本号。适当的值取决于originatorInfo、RecipientInfo和UnprotectedAttr。必须按如下方式分配版本：
IF (originatorInfo is present) AND ((any certificates with a type of other are present) OR (any crls with a type of other are present)) THEN version is 4 ELSE IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) OR (any RecipientInfo structures include pwri) OR (any RecipientInfo structures include ori) THEN version is 3 ELSE IF (originatorInfo is absent) AND (unprotectedAttrs is absent) AND (all RecipientInfo structures are version 0) THEN version is 0 ELSE version is 2
如果（存在originatorInfo）和（（存在任何类型为other的证书）或（存在任何类型为other的CRL）），则版本为4，如果（（存在originatorInfo）和（存在任何版本2属性证书））或（任何RecipientInfo结构包括pwri）或（任何RecipientInfo结构包括ori）则版本为3，否则如果（不存在originatorInfo）和（不存在未受保护的TTR）以及（所有RecipientInfo结构均为版本0），则版本为0，否则版本为2
originatorInfo optionally provides information about the originator. It is present only if required by the key management algorithm. It may contain certificates and CRLs:
originatorInfo可选地提供有关发起人的信息。仅当密钥管理算法需要时才显示。它可能包含证书和CRL：
certs is a collection of certificates. certs may contain originator certificates associated with several different key management algorithms. certs may also contain attribute certificates associated with the originator. The certificates contained in certs are intended to be sufficient for all recipients to build certification paths from a recognized "root" or "top-level certification authority". However, certs may contain more certificates than necessary, and there may be certificates sufficient to make certification paths from two or more independent top-level certification authorities. Alternatively, certs may contain fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessary certificates (e.g., from a previous set of certificates).
证书是证书的集合。证书可能包含与若干不同密钥管理算法相关联的发起人证书。证书还可能包含与发起人关联的属性证书。证书中包含的证书足以让所有收件人从公认的“根”或“顶级证书颁发机构”构建证书路径。但是，证书可能包含的证书比需要的证书多，并且可能有足够的证书从两个或多个独立的顶级证书颁发机构创建证书路径。或者，如果预期接收人具有获取必要证书（例如，从以前的一组证书）的替代方法，则证书可能包含比必要的证书更少的证书。
crls is a collection of CRLs. It is intended that the set contain information sufficient to determine whether or not the certificates in the certs field are valid, but such correspondence is not necessary. There MAY be more CRLs than necessary, and there MAY also be fewer CRLs than necessary.
CRL是CRL的集合。该集合包含足以确定certs字段中的证书是否有效的信息，但这种对应关系不是必需的。CRL可能比需要的多，也可能比需要的少。
recipientInfos is a collection of per-recipient information. There MUST be at least one element in the collection.
recipientInfos是每个收件人信息的集合。集合中必须至少有一个元素。
encryptedContentInfo is the encrypted content information.
encryptedContentInfo是加密的内容信息。
unprotectedAttrs is a collection of attributes that are not encrypted. The field is optional. Useful attribute types are defined in Section 11.
unprotectedAttrs是未加密的属性集合。该字段是可选的。第11节定义了有用的属性类型。
The fields of type EncryptedContentInfo have the following meanings:
EncryptedContentInfo类型的字段具有以下含义：
contentType indicates the type of content.
contentType指示内容的类型。
contentEncryptionAlgorithm identifies the content-encryption algorithm, and any associated parameters, used to encrypt the content. The content-encryption process is described in Section 6.3. The same content-encryption algorithm and content-encryption key are used for all recipients.
contentEncryptionAlgorithm标识用于加密内容的内容加密算法和任何相关参数。第6.3节描述了内容加密过程。所有收件人都使用相同的内容加密算法和内容加密密钥。
encryptedContent is the result of encrypting the content. The field is optional, and if the field is not present, its intended value must be supplied by other means.
encryptedContent是加密内容的结果。该字段是可选的，如果该字段不存在，则必须通过其他方式提供其预期值。
The recipientInfos field comes before the encryptedContentInfo field so that an EnvelopedData value may be processed in a single pass.
recipientInfos字段位于encryptedContentInfo字段之前，因此可以在一次传递中处理EnvelopedData值。
Per-recipient information is represented in the type RecipientInfo. RecipientInfo has a different format for each of the supported key management techniques. Any of the key management techniques can be used for each recipient of the same encrypted content. In all cases, the encrypted content-encryption key is transferred to one or more recipients.
每个收件人的信息在RecipientInfo类型中表示。RecipientInfo对每种受支持的密钥管理技术都有不同的格式。任何密钥管理技术都可以用于相同加密内容的每个收件人。在所有情况下，加密的内容加密密钥都会传输给一个或多个收件人。
Since all implementations will not support every possible key management algorithm, all implementations MUST gracefully handle unimplemented algorithms when they are encountered. For example, if a recipient receives a content-encryption key encrypted in their RSA public key using RSA-OAEP (Optimal Asymmetric Encryption Padding) and the implementation only supports RSA PKCS #1 v1.5, then a graceful failure must be implemented.
由于所有实现都不支持所有可能的密钥管理算法，因此所有实现在遇到未实现的算法时都必须优雅地处理这些算法。例如，如果收件人收到使用RSA-OAEP（最佳非对称加密填充）在其RSA公钥中加密的内容加密密钥，并且该实现仅支持RSA PKCS#1 v1.5，则必须实现正常故障。
Implementations MUST support key transport, key agreement, and previously distributed symmetric key-encryption keys, as represented by ktri, kari, and kekri, respectively. Implementations MAY support the password-based key management as represented by pwri. Implementations MAY support any other key management technique as represented by ori. Since each recipient can employ a different key management technique and future specifications could define additional key management techniques, all implementations MUST gracefully handle unimplemented alternatives within the RecipientInfo CHOICE, all implementations MUST gracefully handle unimplemented versions of otherwise supported alternatives within the RecipientInfo CHOICE, and all implementations MUST gracefully handle unimplemented or unknown ori alternatives.
实现必须支持密钥传输、密钥协商和以前分发的对称密钥加密密钥，分别由ktri、kari和kekri表示。实现可能支持pwri所表示的基于密码的密钥管理。实现可以支持ori表示的任何其他密钥管理技术。由于每个接收者可以使用不同的密钥管理技术，并且未来的规范可以定义其他密钥管理技术，因此所有实现都必须优雅地处理RecipientInfo选项中未实现的替代方案，所有实现都必须优雅地处理RecipientInfo选项中其他受支持备选方案的未实现版本，并且所有实现都必须优雅地处理未实现或未知的ori备选方案。
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING
EncryptedKey ::= OCTET STRING
Per-recipient information using key transport is represented in the type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo transfers the content-encryption key to one recipient.
使用密钥传输的每个收件人信息在类型KeyTransRecipientInfo中表示。KeyTransRecipientInfo的每个实例都将内容加密密钥传输给一个收件人。
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
The fields of type KeyTransRecipientInfo have the following meanings:
KeyTransRecipientInfo类型的字段具有以下含义：
version is the syntax version number. If the RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 0. If the RecipientIdentifier is subjectKeyIdentifier, then the version MUST be 2.
version是语法版本号。如果RecipientIdentifier是选项issuerAndSerialNumber，则版本必须为0。如果RecipientIdentifier是subjectKeyIdentifier，则版本必须为2。
rid specifies the recipient's certificate or key that was used by the sender to protect the content-encryption key. The content-encryption key is encrypted with the recipient's public key. The RecipientIdentifier provides two alternatives for specifying the recipient's certificate, and thereby the recipient's public key. The recipient's certificate must contain a key transport public key. Therefore, a recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyEncipherment bit. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier identifies the recipient's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. For recipient processing, implementations MUST support both of these alternatives for specifying the recipient's certificate. For sender processing, implementations MUST support at least one of these alternatives.
rid指定发件人用于保护内容加密密钥的收件人的证书或密钥。内容加密密钥使用收件人的公钥加密。RecipientIdentifier提供了两种方法来指定收件人的证书，从而指定收件人的公钥。收件人的证书必须包含密钥传输公钥。因此，包含密钥使用扩展的收件人X.509版本3证书必须声明密钥加密位。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；subjectKeyIdentifier通过密钥标识符标识收件人的证书。引用X.509证书时，密钥标识符与X.509 subjectKeyIdentifier扩展值匹配。当引用其他证书格式时，指定证书格式及其在CMS中的使用的文档必须包括有关将密钥标识符匹配到相应证书字段的详细信息。对于收件人处理，实现必须支持这两种方法来指定收件人的证书。对于发送方处理，实现必须至少支持其中一种选择。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the content-encryption key for the recipient. The key-encryption process is described in Section 6.4.
keyEncryptionAlgorithm标识用于为收件人加密内容加密密钥的密钥加密算法和任何相关参数。第6.4节描述了密钥加密过程。
encryptedKey is the result of encrypting the content-encryption key for the recipient.
encryptedKey是为收件人加密内容加密密钥的结果。
Recipient information using key agreement is represented in the type KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will transfer the content-encryption key to one or more recipients that use the same key agreement algorithm and domain parameters for that algorithm.
使用密钥协议的收件人信息在KeyAgreeRecipientInfo类型中表示。KeyAgreeRecipientInfo的每个实例都将内容加密密钥传输给一个或多个使用相同密钥协议算法和该算法域参数的收件人。
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING
SubjectKeyIdentifier ::= OCTET STRING
The fields of type KeyAgreeRecipientInfo have the following meanings:
KeyAgreeRecipientInfo类型的字段具有以下含义：
version is the syntax version number. It MUST always be 3.
version是语法版本号。它必须始终为3。
originator is a CHOICE with three alternatives specifying the sender's key agreement public key. The sender uses the corresponding private key and the recipient's public key to generate a pairwise key. The content-encryption key is encrypted in the pairwise key. The issuerAndSerialNumber alternative identifies the sender's certificate, and thereby the sender's public key, by the issuer's distinguished name and the certificate serial number. The subjectKeyIdentifier alternative identifies the sender's certificate, and thereby the sender's public key, by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. The originatorKey alternative includes the algorithm identifier and sender's key agreement public key. This alternative permits originator anonymity since the public key is not certified. Implementations MUST support all three alternatives for specifying the sender's public key.
发起者是一个选择，有三个选项指定发送者的密钥协议公钥。发送方使用相应的私钥和接收方的公钥生成成对密钥。内容加密密钥在成对密钥中加密。issuerAndSerialNumber替代方案通过颁发者的可分辨名称和证书序列号标识发送者的证书，从而标识发送者的公钥。subjectKeyIdentifier替代方案通过密钥标识符标识发送方的证书，从而标识发送方的公钥。引用X.509证书时，密钥标识符与X.509 subjectKeyIdentifier扩展值匹配。当引用其他证书格式时，指定证书格式及其在CMS中的使用的文档必须包括有关将密钥标识符匹配到相应证书字段的详细信息。OriginateWorkey备选方案包括算法标识符和发送方的密钥协议公钥。此替代方案允许发起者匿名，因为公钥未经认证。实现必须支持指定发送方公钥的所有三种备选方案。
ukm is optional. With some key agreement algorithms, the sender provides a User Keying Material (UKM) to ensure that a different key is generated each time the same two parties generate a pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. Implementations that do not support key agreement algorithms that make use of UKMs MUST gracefully handle the presence of UKMs.
ukm是可选的。通过一些密钥协商算法，发送方提供用户密钥材料（UKM），以确保每次相同的双方生成成对密钥时生成不同的密钥。实现必须接受包含ukm字段的KeyAgreeRecipientInfo序列。不支持使用UKM的密钥协商算法的实现必须优雅地处理UKM的存在。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the content-encryption key with the key-encryption key. The key-encryption process is described in Section 6.4.
keyEncryptionAlgorithm标识用于使用密钥加密密钥加密内容加密密钥的密钥加密算法和任何相关参数。第6.4节描述了密钥加密过程。
recipientEncryptedKeys includes a recipient identifier and encrypted key for one or more recipients. The KeyAgreeRecipientIdentifier is a CHOICE with two alternatives specifying the recipient's certificate, and thereby the recipient's public key, that was used by the sender to generate a pairwise key-encryption key. The recipient's certificate must contain a key agreement public key. Therefore, a recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyAgreement bit. The content-encryption key is encrypted in the pairwise key-encryption key. The issuerAndSerialNumber alternative identifies the recipient's
recipientEncryptedKeys包括收件人标识符和一个或多个收件人的加密密钥。KeyAgreentRecipientIdentifier是一个选项，有两个选项指定接收方的证书，从而指定接收方的公钥，发送方使用该公钥生成成对密钥加密密钥。收件人的证书必须包含密钥协议公钥。因此，包含密钥使用扩展的收件人X.509版本3证书必须声明密钥协议位。内容加密密钥在成对密钥加密密钥中加密。issuerAndSerialNumber替代项标识收件人的
certificate by the issuer's distinguished name and the certificate serial number; the RecipientKeyIdentifier is described below. The encryptedKey is the result of encrypting the content-encryption key in the pairwise key-encryption key generated using the key agreement algorithm. Implementations MUST support both alternatives for specifying the recipient's certificate.
由发行人的可分辨名称和证书序列号出具的证书；RecipientKeyIdentifier如下所述。encryptedKey是对使用密钥协商算法生成的成对密钥加密密钥中的内容加密密钥进行加密的结果。实现必须支持指定收件人证书的两种备选方案。
The fields of type RecipientKeyIdentifier have the following meanings:
RecipientKeyIdentifier类型的字段具有以下含义：
subjectKeyIdentifier identifies the recipient's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field.
subjectKeyIdentifier通过密钥标识符标识收件人的证书。引用X.509证书时，密钥标识符与X.509 subjectKeyIdentifier扩展值匹配。当引用其他证书格式时，指定证书格式及其在CMS中的使用的文档必须包括有关将密钥标识符匹配到相应证书字段的详细信息。
date is optional. When present, the date specifies which of the recipient's previously distributed UKMs was used by the sender.
日期是可选的。当存在时，日期指定发件人使用了收件人以前分发的UKM中的哪一个。
other is optional. When present, this field contains additional information used by the recipient to locate the public keying material used by the sender.
另一个是可选的。如果存在，此字段包含收件人用于查找发件人使用的公钥资料的其他信息。
Recipient information using previously distributed symmetric keys is represented in the type KEKRecipientInfo. Each instance of KEKRecipientInfo will transfer the content-encryption key to one or more recipients who have the previously distributed key-encryption key.
使用以前分发的对称密钥的收件人信息在KEKRecipientInfo类型中表示。KEKRecipientInfo的每个实例都将内容加密密钥传输给一个或多个具有以前分发的密钥加密密钥的收件人。
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
The fields of type KEKRecipientInfo have the following meanings:
KEKRecipientInfo类型的字段具有以下含义：
version is the syntax version number. It MUST always be 4.
version是语法版本号。它必须始终为4。
kekid specifies a symmetric key-encryption key that was previously distributed to the sender and one or more recipients.
kekid指定以前分发给发件人和一个或多个收件人的对称密钥加密密钥。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the content-encryption key with the key-encryption key. The key-encryption process is described in Section 6.4.
keyEncryptionAlgorithm标识用于使用密钥加密密钥加密内容加密密钥的密钥加密算法和任何相关参数。第6.4节描述了密钥加密过程。
encryptedKey is the result of encrypting the content-encryption key in the key-encryption key.
encryptedKey是对密钥加密密钥中的内容加密密钥进行加密的结果。
The fields of type KEKIdentifier have the following meanings:
KEKIdentifier类型的字段具有以下含义：
keyIdentifier identifies the key-encryption key that was previously distributed to the sender and one or more recipients.
keyIdentifier标识以前分发给发件人和一个或多个收件人的密钥加密密钥。
date is optional. When present, the date specifies a single key-encryption key from a set that was previously distributed.
日期是可选的。存在时，日期指定以前分发的一组密钥中的一个密钥加密密钥。
other is optional. When present, this field contains additional information used by the recipient to determine the key-encryption key used by the sender.
另一个是可选的。如果存在，此字段包含收件人用于确定发件人使用的密钥加密密钥的其他信息。
Recipient information using a password or shared secret value is represented in the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo will transfer the content-encryption key to one or more recipients who possess the password or shared secret value.
使用密码或共享秘密值的收件人信息在PasswordRecipientInfo类型中表示。PasswordRecipientInfo的每个实例都会将内容加密密钥传输给一个或多个拥有密码或共享密钥值的收件人。
The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. The PasswordRecipientInfo structure is repeated here for completeness.
密码RecipientInfo类型在RFC 3211[PWRI]中指定。为了完整起见，这里重复PasswordRecipientInfo结构。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings:
PasswordRecipientInfo类型的字段具有以下含义：
version is the syntax version number. It MUST always be 0.
version是语法版本号。它必须始终为0。
keyDerivationAlgorithm identifies the key-derivation algorithm, and any associated parameters, used to derive the key-encryption key from the password or shared secret value. If this field is absent, the key-encryption key is supplied from an external source, for example a hardware crypto token such as a smart card.
KeyDerivationGorithm标识用于从密码或共享密钥值派生密钥加密密钥的密钥派生算法和任何相关参数。如果该字段不存在，则密钥加密密钥由外部源提供，例如硬件加密令牌，如智能卡。
keyEncryptionAlgorithm identifies the encryption algorithm, and any associated parameters, used to encrypt the content-encryption key with the key-encryption key.
keyEncryptionAlgorithm标识用于使用密钥加密密钥加密内容加密密钥的加密算法和任何相关参数。
encryptedKey is the result of encrypting the content-encryption key with the key-encryption key.
encryptedKey是使用密钥加密密钥加密内容加密密钥的结果。
Recipient information for additional key management techniques are represented in the type OtherRecipientInfo. The OtherRecipientInfo type allows key management techniques beyond key transport, key agreement, previously distributed symmetric key-encryption keys, and password-based key management to be specified in future documents. An object identifier uniquely identifies such key management techniques.
其他密钥管理技术的收件人信息在类型OtherRecipientInfo中表示。OtherRecipientInfo类型允许在将来的文档中指定密钥传输、密钥协议、以前分发的对称密钥加密密钥和基于密码的密钥管理以外的密钥管理技术。对象标识符唯一地标识这样的密钥管理技术。
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
The fields of type OtherRecipientInfo have the following meanings:
OtherRecipientInfo类型的字段具有以下含义：
oriType identifies the key management technique.
oriType识别关键管理技术。
oriValue contains the protocol data elements needed by a recipient using the identified key management technique.
oriValue包含接收方使用已识别密钥管理技术所需的协议数据元素。
The content-encryption key for the desired content-encryption algorithm is randomly generated. The data to be protected is padded as described below, then the padded data is encrypted using the content-encryption key. The encryption operation maps an arbitrary string of octets (the data) to another string of octets (the ciphertext) under control of a content-encryption key. The encrypted data is included in the EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.
随机生成所需内容加密算法的内容加密密钥。要保护的数据如下所述进行填充，然后使用内容加密密钥对填充的数据进行加密。加密操作在内容加密密钥的控制下，将任意八进制字符串（数据）映射到另一个八进制字符串（密文）。加密数据包含在EnvelopedData encryptedContentInfo encryptedContent八位字节字符串中。
Some content-encryption algorithms assume the input length is a multiple of k octets, where k is greater than one. For such algorithms, the input shall be padded at the trailing end with k-(lth mod k) octets all having value k-(lth mod k), where lth is the length of the input. In other words, the input is padded at the trailing end with one of the following strings:
一些内容加密算法假定输入长度是k个八位字节的倍数，其中k大于1。对于此类算法，输入应在尾端用k-（lth mod k）个八位字节填充，所有八位字节的值均为k-（lth mod k），其中lth是输入的长度。换句话说，输入在尾端用以下字符串之一填充：
01 -- if lth mod k = k-1 02 02 -- if lth mod k = k-2 . . . k k ... k k -- if lth mod k = 0
01--如果lth mod k=k-1 02--如果lth mod k=k-2。k k。。。k—如果lth mod k=0
The padding can be removed unambiguously since all input is padded, including input values that are already a multiple of the block size, and no padding string is a suffix of another. This padding method is well defined if and only if k is less than 256.
填充可以被明确地删除，因为所有输入都被填充，包括已经是块大小的倍数的输入值，并且没有填充字符串是另一个的后缀。当且仅当k小于256时，此填充方法定义良好。
The input to the key-encryption process -- the value supplied to the recipient's key-encryption algorithm -- is just the "value" of the content-encryption key.
密钥加密过程的输入——提供给接收方密钥加密算法的值——只是内容加密密钥的“值”。
Any of the aforementioned key management techniques can be used for each recipient of the same encrypted content.
上述任何密钥管理技术可用于相同加密内容的每个接收者。
The digested-data content type consists of content of any type and a message digest of the content.
摘要数据内容类型由任何类型的内容和内容的消息摘要组成。
Typically, the digested-data content type is used to provide content integrity, and the result generally becomes an input to the enveloped-data content type.
通常，摘要数据内容类型用于提供内容完整性，结果通常成为信封数据内容类型的输入。
The following steps construct digested-data:
以下步骤构造摘要数据：
1. A message digest is computed on the content with a message-digest algorithm.
1. 使用消息摘要算法对内容计算消息摘要。
2. The message-digest algorithm and the message digest are collected together with the content into a DigestedData value.
2. 消息摘要算法和消息摘要与内容一起收集到一个DigestedData值中。
A recipient verifies the message digest by comparing the message digest to an independently computed message digest.
收件人通过将邮件摘要与独立计算的邮件摘要进行比较来验证邮件摘要。
The following object identifier identifies the digested-data content type:
以下对象标识符标识摘要数据内容类型：
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
The digested-data content type shall have ASN.1 type DigestedData:
摘要数据内容类型应具有ASN.1类型摘要数据：
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
Digest ::= OCTET STRING
Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings:
DigestedData类型的字段具有以下含义：
version is the syntax version number. If the encapsulated content type is id-data, then the value of version MUST be 0; however, if the encapsulated content type is other than id-data, then the value of version MUST be 2.
version是语法版本号。如果封装的内容类型为id数据，则版本值必须为0；但是，如果封装的内容类型不是id数据，则version的值必须为2。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, under which the content is digested. The message-digesting process is the same as in Section 5.4 in the case when there are no signed attributes.
digestAlgorithm标识消息摘要算法和任何相关参数，在这些参数下内容被摘要化。在没有签名属性的情况下，消息摘要处理过程与第5.4节相同。
encapContentInfo is the content that is digested, as defined in Section 5.2.
encapContentInfo是第5.2节中定义的摘要内容。
digest is the result of the message-digesting process.
摘要是消息摘要处理的结果。
The ordering of the digestAlgorithm field, the encapContentInfo field, and the digest field makes it possible to process a DigestedData value in a single pass.
digestAlgorithm字段、encapContentInfo字段和digest字段的顺序使得可以在单个过程中处理DigestedData值。
The encrypted-data content type consists of encrypted content of any type. Unlike the enveloped-data content type, the encrypted-data content type has neither recipients nor encrypted content-encryption keys. Keys MUST be managed by other means.
加密数据内容类型由任何类型的加密内容组成。与信封数据内容类型不同，加密数据内容类型既没有收件人，也没有加密内容加密密钥。密钥必须通过其他方式进行管理。
The typical application of the encrypted-data content type will be to encrypt the content of the data content type for local storage, perhaps where the encryption key is derived from a password.
加密数据内容类型的典型应用是加密本地存储的数据内容类型的内容，可能其中加密密钥来自密码。
The following object identifier identifies the encrypted-data content type:
以下对象标识符标识加密的数据内容类型：
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
The encrypted-data content type shall have ASN.1 type EncryptedData:
加密数据内容类型应具有ASN.1类型加密数据：
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
The fields of type EncryptedData have the following meanings:
EncryptedData类型的字段具有以下含义：
version is the syntax version number. If unprotectedAttrs is present, then the version MUST be 2. If unprotectedAttrs is absent, then version MUST be 0.
version是语法版本号。如果存在未受保护的TTRS，则版本必须为2。如果不存在未受保护的TTR，则版本必须为0。
encryptedContentInfo is the encrypted content information, as defined in Section 6.1.
encryptedContentInfo是第6.1节中定义的加密内容信息。
unprotectedAttrs is a collection of attributes that are not encrypted. The field is optional. Useful attribute types are defined in Section 11.
unprotectedAttrs是未加密的属性集合。该字段是可选的。第11节定义了有用的属性类型。
The authenticated-data content type consists of content of any type, a message authentication code (MAC), and encrypted authentication keys for one or more recipients. The combination of the MAC and one encrypted authentication key for a recipient is necessary for that recipient to verify the integrity of the content. Any type of content can be integrity protected for an arbitrary number of recipients.
经过身份验证的数据内容类型包括任何类型的内容、消息身份验证码（MAC）和一个或多个收件人的加密身份验证密钥。MAC和收件人的一个加密身份验证密钥的组合对于该收件人验证内容的完整性是必要的。任何类型的内容都可以为任意数量的收件人提供完整性保护。
The process by which authenticated-data is constructed involves the following steps:
构造经过身份验证的数据的过程包括以下步骤：
1. A message-authentication key for a particular message-authentication algorithm is generated at random.
1. 随机生成特定消息认证算法的消息认证密钥。
2. The message-authentication key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used.
2. 为每个收件人加密邮件身份验证密钥。此加密的详细信息取决于所使用的密钥管理算法。
3. For each recipient, the encrypted message-authentication key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2.
3. 对于每个收件人，加密的邮件身份验证密钥和其他特定于收件人的信息被收集到第6.2节中定义的RecipientInfo值中。
4. Using the message-authentication key, the originator computes a MAC value on the content. If the originator is authenticating any information in addition to the content (see Section 9.2), a message digest is calculated on the content, the message digest of the content and the other information are authenticated using the message-authentication key, and the result becomes the "MAC value".
4. 发端人使用消息身份验证密钥计算内容上的MAC值。如果发端人正在验证除内容外的任何信息（见第9.2节），则对内容计算消息摘要，使用消息验证密钥验证内容和其他信息的消息摘要，结果成为“MAC值”。
The following object identifier identifies the authenticated-data content type:
以下对象标识符标识经过身份验证的数据内容类型：
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
The authenticated-data content type shall have ASN.1 type AuthenticatedData:
认证数据内容类型应具有ASN.1类型认证数据：
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING
MessageAuthenticationCode ::= OCTET STRING
The fields of type AuthenticatedData have the following meanings:
AuthenticatedData类型的字段具有以下含义：
version is the syntax version number. The version MUST be assigned as follows:
version是语法版本号。必须按如下方式分配版本：
IF (originatorInfo is present) AND ((any certificates with a type of other are present) OR (any crls with a type of other are present)) THEN version is 3 ELSE IF ((originatorInfo is present) AND (any version 2 attribute certificates are present)) THEN version is 1 ELSE version is 0
如果（存在originatorInfo）和（（存在任何类型为other的证书）或（存在任何类型为other的CRL）），则版本为3，否则如果（（存在originatorInfo）和（存在任何版本2属性证书）），则版本为1，否则版本为0
originatorInfo optionally provides information about the originator. It is present only if required by the key management algorithm. It MAY contain certificates, attribute certificates, and CRLs, as defined in Section 6.1.
originatorInfo可选地提供有关发起人的信息。仅当密钥管理算法需要时才显示。它可能包含第6.1节中定义的证书、属性证书和CRL。
recipientInfos is a collection of per-recipient information, as defined in Section 6.1. There MUST be at least one element in the collection.
recipientInfos是第6.1节中定义的每个收件人信息的集合。集合中必须至少有一个元素。
macAlgorithm is a message authentication code (MAC) algorithm identifier. It identifies the MAC algorithm, along with any associated parameters, used by the originator. Placement of the macAlgorithm field facilitates one-pass processing by the recipient.
macAlgorithm是一种消息身份验证码（MAC）算法标识符。它确定了发起人使用的MAC算法以及任何相关参数。macAlgorithm字段的放置有助于收件人进行一次性处理。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used to compute a message digest on the encapsulated content if authenticated attributes are present. The message digesting process is described in Section 9.2. Placement of the digestAlgorithm field facilitates one-pass processing by the recipient. If the digestAlgorithm field is present, then the authAttrs field MUST also be present.
digestAlgorithm标识消息摘要算法和任何相关参数，如果存在经过身份验证的属性，则用于计算封装内容上的消息摘要。第9.2节描述了消息摘要处理过程。digestAlgorithm字段的放置有助于收件人进行一次性处理。如果digestAlgorithm字段存在，则authAttrs字段也必须存在。
encapContentInfo is the content that is authenticated, as defined in Section 5.2.
encapContentInfo是第5.2节中定义的经过身份验证的内容。
authAttrs is a collection of authenticated attributes. The authAttrs structure is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being authenticated is not id-data. If the authAttrs field is present, then the digestAlgorithm field MUST also be present. The AuthAttributes structure MUST be DER encoded, even if the rest of the structure is BER encoded. Useful attribute types are defined in Section 11. If the authAttrs field is present, it MUST contain, at a minimum, the following two attributes:
authAttrs是经过身份验证的属性的集合。authAttrs结构是可选的，但如果要验证的封装ContentInfo值的内容类型不是id数据，则必须存在该结构。如果存在authAttrs字段，则digestAlgorithm字段也必须存在。AuthAttributes结构必须进行DER编码，即使结构的其余部分是BER编码的。第11节定义了有用的属性类型。如果存在authAttrs字段，则它必须至少包含以下两个属性：
A content-type attribute having as its value the content type of the EncapsulatedContentInfo value being authenticated. Section 11.1 defines the content-type attribute.
一种内容类型属性，其值为正在验证的封装ContentInfo值的内容类型。第11.1节定义了内容类型属性。
A message-digest attribute, having as its value the message digest of the content. Section 11.2 defines the message-digest attribute.
消息摘要属性，其值为内容的消息摘要。第11.2节定义了消息摘要属性。
mac is the message authentication code.
mac是消息身份验证代码。
unauthAttrs is a collection of attributes that are not authenticated. The field is optional. To date, no attributes have been defined for use as unauthenticated attributes, but other useful attribute types are defined in Section 11.
unauthAttrs是未经身份验证的属性集合。该字段是可选的。到目前为止，尚未定义任何属性用作未经验证的属性，但第11节中定义了其他有用的属性类型。
The MAC calculation process computes a message authentication code (MAC) on either the content being authenticated or a message digest of content being authenticated together with the originator's authenticated attributes.
MAC计算过程在正在被认证的内容或正在被认证的内容的消息摘要上计算消息认证码（MAC）以及发起人的认证属性。
If the authAttrs field is absent, the input to the MAC calculation process is the value of the encapContentInfo eContent OCTET STRING. Only the octets comprising the value of the eContent OCTET STRING are input to the MAC algorithm; the tag and the length octets are omitted. This has the advantage that the length of the content being authenticated need not be known in advance of the MAC generation process.
如果缺少authAttrs字段，则MAC计算过程的输入是encapContentInfo eContent八位字符串的值。只有包含eContent八位元字符串值的八位元被输入到MAC算法；省略标记和长度八位字节。这具有这样的优点，即在MAC生成过程之前不需要知道被认证的内容的长度。
If the authAttrs field is present, the content-type attribute (as described in Section 11.1) and the message-digest attribute (as described in Section 11.2) MUST be included, and the input to the MAC calculation process is the DER encoding of authAttrs. A separate encoding of the authAttrs field is performed for message digest calculation. The IMPLICIT [2] tag in the authAttrs field is not used for the DER encoding, rather an EXPLICIT SET OF tag is used. That is, the DER encoding of the SET OF tag, rather than of the IMPLICIT [2] tag, is to be included in the message digest calculation along with the length and content octets of the authAttrs value.
如果存在authAttrs字段，则必须包括内容类型属性（如第11.1节所述）和消息摘要属性（如第11.2节所述），MAC计算过程的输入是authAttrs的DER编码。authAttrs字段的单独编码用于消息摘要计算。authAttrs字段中的隐式[2]标记不用于DER编码，而是使用一组显式标记。也就是说，标记集（而不是隐式[2]标记）的DER编码将与authAttrs值的长度和内容八位字节一起包含在消息摘要计算中。
The message digest calculation process computes a message digest on the content being authenticated. The initial input to the message digest calculation process is the "value" of the encapsulated content being authenticated. Specifically, the input is the encapContentInfo eContent OCTET STRING to which the authentication process is applied. Only the octets comprising the value of the encapContentInfo eContent OCTET STRING are input to the message digest algorithm, not the tag
消息摘要计算过程计算正在验证的内容的消息摘要。消息摘要计算过程的初始输入是正在验证的封装内容的“值”。具体来说，输入是应用身份验证过程的encapContentInfo eContent八位字节字符串。只有包含encapContentInfo eContent八位元字符串值的八位元被输入到消息摘要算法，而不是标记
or the length octets. This has the advantage that the length of the content being authenticated need not be known in advance. Although the encapContentInfo eContent OCTET STRING tag and length octets are not included in the message digest calculation, they are still protected by other means. The length octets are protected by the nature of the message digest algorithm since it is computationally infeasible to find any two distinct contents of any length that have the same message digest.
或者长度八位字节。这样做的优点是不需要预先知道被认证内容的长度。尽管encapContentInfo eContent八位字节字符串标记和长度八位字节不包括在消息摘要计算中，但它们仍然受到其他方式的保护。长度八位字节受消息摘要算法的性质保护，因为在计算上不可能找到具有相同消息摘要的任何长度的任何两个不同内容。
The input to the MAC calculation process includes the MAC input data, defined above, and an authentication key conveyed in a recipientInfo structure. The details of MAC calculation depend on the MAC algorithm employed (e.g., Hashed Message Authentication Code (HMAC)). The object identifier, along with any parameters, that specifies the MAC algorithm employed by the originator is carried in the macAlgorithm field. The MAC value generated by the originator is encoded as an OCTET STRING and carried in the mac field.
对MAC计算处理的输入包括上面定义的MAC输入数据和在recipientInfo结构中传送的认证密钥。MAC计算的细节取决于所采用的MAC算法（例如，哈希消息认证码（HMAC））。macAlgorithm字段中包含指定发起人采用的MAC算法的对象标识符以及任何参数。发起者生成的MAC值被编码为八位字节字符串，并携带在MAC字段中。
The input to the MAC verification process includes the input data (determined based on the presence or absence of the authAttrs field, as defined in 9.2), and the authentication key conveyed in recipientInfo. The details of the MAC verification process depend on the MAC algorithm employed.
MAC验证过程的输入包括输入数据（根据9.2中定义的authAttrs字段的存在与否确定）和recipientInfo中传递的认证密钥。MAC验证过程的细节取决于所采用的MAC算法。
The recipient MUST NOT rely on any MAC values or message digest values computed by the originator. The content is authenticated as described in Section 9.2. If the originator includes authenticated attributes, then the content of the authAttrs is authenticated as described in Section 9.2. For authentication to succeed, the MAC value calculated by the recipient MUST be the same as the value of the mac field. Similarly, for authentication to succeed when the authAttrs field is present, the content message digest value calculated by the recipient MUST be the same as the message digest value included in the authAttrs message-digest attribute.
收件人不得依赖发端人计算的任何MAC值或消息摘要值。内容按照第9.2节所述进行认证。如果发起人包括已验证的属性，则按照第9.2节中的说明对authAttrs的内容进行验证。要使身份验证成功，收件人计算的MAC值必须与MAC字段的值相同。类似地，要在存在authAttrs字段时成功进行身份验证，收件人计算的内容消息摘要值必须与authAttrs消息摘要属性中包含的消息摘要值相同。
If the AuthenticatedData includes authAttrs, then the content-type attribute value MUST match the AuthenticatedData encapContentInfo eContentType value.
如果AuthenticatedData包括authAttrs，则内容类型属性值必须与AuthenticatedData encapContentInfo eContentType值匹配。
This section is divided into two parts. The first part defines algorithm identifiers, and the second part defines other useful types.
本节分为两部分。第一部分定义了算法标识符，第二部分定义了其他有用的类型。
All of the algorithm identifiers have the same type: AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken from X.509 [X.509-88].
所有算法标识符都具有相同的类型：AlgorithmIdentifier。算法识别器的定义取自X.509[X.509-88]。
There are many alternatives for each algorithm type.
每种算法类型都有许多备选方案。
The DigestAlgorithmIdentifier type identifies a message-digest algorithm. Examples include SHA-1, MD2, and MD5. A message-digest algorithm maps an octet string (the content) to another octet string (the message digest).
DigestAlgorithmIdentifier类型标识消息摘要算法。示例包括SHA-1、MD2和MD5。消息摘要算法将一个八位字节字符串（内容）映射到另一个八位字节字符串（消息摘要）。
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest algorithm. Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with SHA-256. A signature algorithm supports signature generation and verification operations. The signature generation operation uses the message digest and the signer's private key to generate a signature value. The signature verification operation uses the message digest and the signer's public key to determine whether or not a signature value is valid. Context determines which operation is intended.
SignatureAlgorithmIdentifier类型标识签名算法，还可以标识消息摘要算法。示例包括RSA、DSA、带SHA-1的DSA、ECDSA和带SHA-256的ECDSA。签名算法支持签名生成和验证操作。签名生成操作使用消息摘要和签名者的私钥生成签名值。签名验证操作使用消息摘要和签名者的公钥来确定签名值是否有效。上下文确定要执行的操作。
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption algorithm used to encrypt a content-encryption key. The encryption operation maps an octet string (the key) to another octet string (the encrypted key) under control of a key-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
KeyEncryptionAlgorithmIdentifier类型标识用于加密内容加密密钥的密钥加密算法。加密操作在密钥加密密钥的控制下将一个八位字节字符串（密钥）映射到另一个八位字节字符串（加密密钥）。解密操作与加密操作相反。上下文确定要执行的操作。
The details of encryption and decryption depend on the key management algorithm used. Key transport, key agreement, previously distributed symmetric key-encrypting keys, and symmetric key-encrypting keys derived from passwords are supported.
加密和解密的细节取决于使用的密钥管理算法。支持密钥传输、密钥协商、以前分发的对称密钥加密密钥以及从密码派生的对称密钥加密密钥。
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
The ContentEncryptionAlgorithmIdentifier type identifies a content-encryption algorithm. Examples include Triple-DES and RC2. A content-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the plaintext) to another octet string (the ciphertext) under control of a content-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
ContentEncryptionAlgorithmIdentifier类型标识内容加密算法。示例包括三重DES和RC2。内容加密算法支持加密和解密操作。加密操作在内容加密密钥的控制下将一个八位字符串（明文）映射到另一个八位字符串（密文）。解密操作与加密操作相反。上下文确定要执行的操作。
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
The MessageAuthenticationCodeAlgorithm type identifies a message authentication code (MAC) algorithm. Examples include DES-MAC and HMAC-SHA-1. A MAC algorithm supports generation and verification operations. The MAC generation and verification operations use the same symmetric key. Context determines which operation is intended.
MessageAuthenticationCodeAlgorithm类型标识消息身份验证代码（MAC）算法。示例包括DES-MAC和HMAC-SHA-1。MAC算法支持生成和验证操作。MAC生成和验证操作使用相同的对称密钥。上下文确定要执行的操作。
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
The KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated here for completeness.
RFC 3211[PWRI]中指定了KeyDerivationAlgorithmIdentifier类型。为了完整起见，这里重复了KeyDerivationGorithMidentifier定义。
Key derivation algorithms convert a password or shared secret value into a key-encryption key.
密钥派生算法将密码或共享秘密值转换为密钥加密密钥。
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
This section defines types that are used other places in the document. The types are not listed in any particular order.
本节定义文档中其他位置使用的类型。这些类型没有按任何特定顺序列出。
The RevocationInfoChoices type gives a set of revocation status information alternatives. It is intended that the set contain information sufficient to determine whether the certificates and attribute certificates with which the set is associated are revoked. However, there MAY be more revocation status information than necessary or there MAY be less revocation status information than necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are
RevocationFochoices类型提供一组撤销状态信息。该集合包含足以确定与该集合关联的证书和属性证书是否被吊销的信息。然而，撤销状态信息可能比需要的多，或者撤销状态信息可能比需要的少。X.509证书撤销列表（CRL）[X.509-97]为
the primary source of revocation status information, but any other revocation information format can be supported. The OtherRevocationInfoFormat alternative is provided to support any other revocation information format without further modifications to the CMS. For example, Online Certificate Status Protocol (OCSP) Responses [OCSP] can be supported using the OtherRevocationInfoFormat.
吊销状态信息的主要来源，但可以支持任何其他吊销信息格式。提供OtherRevocationInfo格式替代方案，以支持任何其他撤销信息格式，而无需对CMS进行进一步修改。例如，可以使用OtherRevocationInfo格式支持联机证书状态协议（OCSP）响应[OCSP]。
The CertificateList may contain a CRL, an Authority Revocation List (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All of these lists share a common syntax.
证书列表可以包含CRL、授权撤销列表（ARL）、增量CRL或属性证书撤销列表。所有这些列表都有一个共同的语法。
The CertificateList type gives a certificate revocation list (CRL). CRLs are specified in X.509 [X.509-97], and they are profiled for use in the Internet in RFC 5280 [PROFILE].
CertificateList类型提供证书吊销列表（CRL）。CRL在X.509[X.509-97]中有规定，并在RFC 5280[PROFILE]中对其进行了分析，以供在互联网上使用。
The definition of CertificateList is taken from X.509.
证书列表的定义取自X.509。
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
The CertificateChoices type gives either a PKCS #6 extended certificate [PKCS#6], an X.509 certificate, a version 1 X.509 attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute certificate (ACv2) [X.509-00], or any other certificate format. The PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is included for backward compatibility, and PKCS #6 certificates SHOULD NOT be used. The ACv1 is also obsolete. ACv1 is included for backward compatibility, and ACv1 SHOULD NOT be used. The Internet profile of X.509 certificates is specified in the "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet profile of ACv2 is specified in the "An Internet Attribute Certificate Profile for Authorization" [ACPROFILE]. The OtherCertificateFormat alternative is provided to support any other certificate format without further modifications to the CMS.
CertificateChoices类型提供PKCS#6扩展证书[PKCS#6]、X.509证书、版本1 X.509属性证书（ACv1）[X.509-97]、版本2 X.509属性证书（ACv2）[X.509-00]或任何其他证书格式。PKCS#6扩展证书已过时。包含PKCS#6证书是为了向后兼容，不应使用PKCS#6证书。ACv1也已过时。包含ACv1是为了向后兼容，不应使用ACv1。X.509证书的Internet配置文件在“Internet X.509公钥基础设施：证书和CRL配置文件”[配置文件]中指定。ACv2的Internet配置文件在“授权的Internet属性证书配置文件”[ACPROFILE]中指定。OtherCertificateFormat替代方案用于支持任何其他证书格式，而无需对CMS进行进一步修改。
The definition of Certificate is taken from X.509.
证书的定义取自X.509。
The definitions of AttributeCertificate are taken from X.509-1997 and X.509-2000. The definition from X.509-1997 is assigned to AttributeCertificateV1 (see Section 12.2), and the definition from X.509-2000 is assigned to AttributeCertificateV2.
属性证书的定义取自X.509-1997和X.509-2000。X.509-1997中的定义分配给AttributeCertificateV1（见第12.2节），X.509-2000中的定义分配给AttributeCertificateV2。
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat }
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat }
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat }
The CertificateSet type provides a set of certificates. It is intended that the set be sufficient to contain certification paths from a recognized "root" or "top-level certification authority" to all of the sender certificates with which the set is associated. However, there may be more certificates than necessary, or there MAY be fewer than necessary.
CertificateSet类型提供一组证书。其目的是该集足以包含从已识别的“根”或“顶级证书颁发机构”到与该集关联的所有发送方证书的证书路径。但是，证书可能比需要的多，也可能比需要的少。
The precise meaning of a "certification path" is outside the scope of this document. However, [PROFILE] provides a definition for X.509 certificates. Some applications may impose upper limits on the length of a certification path; others may enforce certain relationships between the subjects and issuers of certificates within a certification path.
“认证路径”的确切含义不在本文件范围内。但是，[PROFILE]提供了X.509证书的定义。一些应用程序可能会对认证路径的长度施加上限；其他人可能会在认证路径中强制执行主体和证书颁发者之间的某些关系。
CertificateSet ::= SET OF CertificateChoices
CertificateSet ::= SET OF CertificateChoices
The IssuerAndSerialNumber type identifies a certificate, and thereby an entity and a public key, by the distinguished name of the certificate issuer and an issuer-specific certificate serial number.
IssuerAndSerialNumber类型通过证书颁发者的可分辨名称和特定于颁发者的证书序列号来标识证书，从而标识实体和公钥。
The definition of Name is taken from X.501 [X.501-88], and the definition of CertificateSerialNumber is taken from X.509 [X.509-97].
名称的定义取自X.501[X.501-88]，证书序列号的定义取自X.509[X.509-97]。
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber ::= INTEGER
The CMSVersion type gives a syntax version number, for compatibility with future revisions of this specification.
CMSVersion类型提供语法版本号，以便与本规范的未来版本兼容。
CMSVersion ::= INTEGER
{ v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
CMSVersion ::= INTEGER
{ v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
The UserKeyingMaterial type gives a syntax for user keying material (UKM). Some key agreement algorithms require UKMs to ensure that a different key is generated each time the same two parties generate a pairwise key. The sender provides a UKM for use with a specific key agreement algorithm.
UserKeyingMaterial类型提供了用户键控材质（UKM）的语法。一些密钥协商算法要求UKM确保每次相同的双方生成成对密钥时生成不同的密钥。发送方提供一个UKM，用于特定的密钥协商算法。
UserKeyingMaterial ::= OCTET STRING
UserKeyingMaterial ::= OCTET STRING
The OtherKeyAttribute type gives a syntax for the inclusion of other key attributes that permit the recipient to select the key used by the sender. The attribute object identifier must be registered along with the syntax of the attribute itself. Use of this structure should be avoided since it might impede interoperability.
OtherKeyAttribute类型提供了包含其他密钥属性的语法，允许收件人选择发件人使用的密钥。属性对象标识符必须与属性本身的语法一起注册。应避免使用此结构，因为它可能会妨碍互操作性。
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
This section defines attributes that may be used with signed-data, enveloped-data, encrypted-data, or authenticated-data. The syntax of Attribute is compatible with X.501 [X.501-88] and RFC 5280 [PROFILE]. Some of the attributes defined in this section were originally defined in PKCS #9 [PKCS#9]; others were originally defined in a previous version of this specification [CMS1]. The attributes are not listed in any particular order.
本节定义了可用于签名数据、信封数据、加密数据或认证数据的属性。属性的语法与X.501[X.501-88]和RFC 5280[PROFILE]兼容。本节中定义的一些属性最初是在PKCS#9[PKCS#9]中定义的；其他最初在本规范的早期版本[CMS1]中定义。属性没有按任何特定顺序列出。
Additional attributes are defined in many places, notably the S/MIME Version 3.1 Message Specification [MSG3.1] and the Enhanced Security Services for S/MIME [ESS], which also include recommendations on the placement of these attributes.
在许多地方定义了其他属性，特别是S/MIME版本3.1消息规范[MSG3.1]和S/MIME增强安全服务[ESS]，其中还包括关于这些属性放置的建议。
The content-type attribute type specifies the content type of the ContentInfo within signed-data or authenticated-data. The content-type attribute type MUST be present whenever signed attributes are present in signed-data or authenticated attributes present in authenticated-data. The content-type attribute value MUST match the encapContentInfo eContentType value in the signed-data or authenticated-data.
content type属性type指定签名数据或身份验证数据中ContentInfo的内容类型。每当签名数据中存在签名属性或已验证数据中存在已验证属性时，内容类型属性类型必须存在。内容类型属性值必须与签名数据或已验证数据中的encapContentInfo eContentType值匹配。
The content-type attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute.
内容类型属性必须是已签名属性或已验证属性；它不能是未签名的属性、未经身份验证的属性或未受保护的属性。
The following object identifier identifies the content-type attribute:
以下对象标识符标识内容类型属性：
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
Content-type attribute values have ASN.1 type ContentType:
内容类型属性值具有ASN.1类型ContentType:
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
Even though the syntax is defined as a SET OF AttributeValue, a content-type attribute MUST have a single attribute value; zero or multiple instances of AttributeValue are not permitted.
即使语法定义为一组AttributeValue，内容类型属性也必须具有单个属性值；不允许AttributeValue的零个或多个实例。
The SignedAttributes and AuthAttributes syntaxes are each defined as a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the content-type attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST NOT include multiple instances of the content-type attribute.
SignedAttribute和AuthAttributes语法都定义为一组属性。signerInfo中的SignedAttribute不能包含content type属性的多个实例。类似地，AuthenticatedData中的AuthAttributes不得包含content type属性的多个实例。
The message-digest attribute type specifies the message digest of the encapContentInfo eContent OCTET STRING being signed in signed-data (see Section 5.4) or authenticated in authenticated-data (see Section 9.2). For signed-data, the message digest is computed using the signer's message digest algorithm. For authenticated-data, the message digest is computed using the originator's message digest algorithm.
message digest属性类型指定encapContentInfo eContent八进制字符串的消息摘要，该字符串在签名数据中签名（请参见第5.4节）或在已验证数据中验证（请参见第9.2节）。对于签名数据，使用签名者的消息摘要算法计算消息摘要。对于经过身份验证的数据，使用发起者的消息摘要算法计算消息摘要。
Within signed-data, the message-digest signed attribute type MUST be present when there are any signed attributes present. Within authenticated-data, the message-digest authenticated attribute type MUST be present when there are any authenticated attributes present.
在签名数据中，当存在任何签名属性时，消息摘要签名属性类型必须存在。在经过身份验证的数据中，当存在任何经过身份验证的属性时，必须存在消息摘要身份验证的属性类型。
The message-digest attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute.
消息摘要属性必须是已签名属性或已验证属性；它不能是未签名的属性、未经身份验证的属性或未受保护的属性。
The following object identifier identifies the message-digest attribute:
以下对象标识符标识消息摘要属性：
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
Message-digest attribute values have ASN.1 type MessageDigest:
消息摘要属性值具有ASN.1类型的消息摘要：
MessageDigest ::= OCTET STRING
MessageDigest ::= OCTET STRING
A message-digest attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present.
消息摘要属性必须具有单个属性值，即使语法定义为一组AttributeValue。AttributeValue的实例不能为零或多个。
The SignedAttributes syntax and AuthAttributes syntax are each defined as a SET OF Attributes. The SignedAttributes in a signerInfo MUST include only one instance of the message-digest attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST include only one instance of the message-digest attribute.
SignedAttribute语法和AuthAttributes语法都定义为一组属性。signerInfo中的SignedAttribute只能包含消息摘要属性的一个实例。类似地，AuthenticatedData中的AuthAttributes必须仅包含消息摘要属性的一个实例。
The signing-time attribute type specifies the time at which the signer (purportedly) performed the signing process. The signing-time attribute type is intended for use in signed-data.
签名时间属性类型指定签名者（据称）执行签名过程的时间。签名时间属性类型用于签名数据。
The signing-time attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute.
签名时间属性必须是已签名属性或已验证属性；它不能是未签名的属性、未经身份验证的属性或未受保护的属性。
The following object identifier identifies the signing-time attribute:
以下对象标识符标识签名时间属性：
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
Signing-time attribute values have ASN.1 type SigningTime:
签名时间属性值具有ASN.1类型签名时间：
SigningTime ::= Time
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Note: The definition of Time matches the one specified in the 1997 version of X.509 [X.509-97].
注：时间的定义与1997年版本的X.509[X.509-97]中规定的时间一致。
Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be encoded as UTCTime. Any dates with year values before 1950 or after 2049 MUST be encoded as GeneralizedTime.
1950年1月1日至2049年12月31日（含）之间的日期必须编码为UTCTime。年份值在1950年之前或2049年之后的任何日期都必须编码为GeneratedTime。
UTCTime values MUST be expressed in Coordinated Universal Time (formerly known as Greenwich Mean Time (GMT) and Zulu clock time) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. Midnight MUST be represented as "YYMMDD000000Z". Century information is implicit, and the century MUST be determined as follows:
UTCTime值必须以协调世界时（以前称为格林威治标准时间（GMT）和祖鲁时钟时间）表示，并且必须包括秒（即时间为YYMMDDHHMMSZ），即使秒数为零。午夜必须表示为“YYMMDD000000Z”。世纪信息是隐含的，世纪必须按以下方式确定：
Where YY is greater than or equal to 50, the year MUST be interpreted as 19YY; and
如果YY大于或等于50，则年份必须解释为19YY；和
Where YY is less than 50, the year MUST be interpreted as 20YY.
如果YY小于50，则年份必须解释为20YY。
GeneralizedTime values MUST be expressed in Coordinated Universal Time and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
泛化时间值必须以协调通用时间表示，并且必须包括秒（即，时间为YYYYMMDDHHMMSSZ），即使秒数为零。GeneralizedTime值不能包含小数秒。
A signing-time attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present.
签名时间属性必须具有单个属性值，即使语法定义为一组AttributeValue。AttributeValue的实例不能为零或多个。
The SignedAttributes syntax and the AuthAttributes syntax are each defined as a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the signing-time attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST NOT include multiple instances of the signing-time attribute.
SignedAttribute语法和AuthAttributes语法都定义为一组属性。signerInfo中的SignedAttribute不能包含signing time属性的多个实例。类似地，AuthenticatedData中的AuthAttributes不得包含签名时间属性的多个实例。
No requirement is imposed concerning the correctness of the signing time, and acceptance of a purported signing time is a matter of a recipient's discretion. It is expected, however, that some signers, such as time-stamp servers, will be trusted implicitly.
没有对签字时间的正确性提出任何要求，接受所谓的签字时间是接收人的自由裁量权。但是，预计某些签名者（如时间戳服务器）将受到隐式信任。
The countersignature attribute type specifies one or more signatures on the contents octets of the signature OCTET STRING in a SignerInfo value of the signed-data. That is, the message digest is computed over the octets comprising the value of the OCTET STRING, neither the tag nor length octets are included. Thus, the countersignature attribute type countersigns (signs in serial) another signature.
“会签”属性类型指定已签名数据的SignerInfo值中签名八位组字符串内容八位组上的一个或多个签名。也就是说，消息摘要是在包含八位字节字符串值的八位字节上计算的，不包括标记和长度八位字节。因此，会签属性类型会签（串行签名）另一个签名。
The countersignature attribute MUST be an unsigned attribute; it MUST NOT be a signed attribute, an authenticated attribute, an unauthenticated attribute, or an unprotected attribute.
副署属性必须是未签名属性；它不能是经过签名的属性、经过身份验证的属性、未经身份验证的属性或未受保护的属性。
The following object identifier identifies the countersignature attribute:
以下对象标识符标识会签属性：
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
Countersignature attribute values have ASN.1 type Countersignature:
会签属性值具有ASN.1类型的会签：
Countersignature ::= SignerInfo
Countersignature ::= SignerInfo
Countersignature values have the same meaning as SignerInfo values for ordinary signatures, except that:
会签值的含义与普通签名的SignerInfo值相同，但以下情况除外：
1. The signedAttributes field MUST NOT contain a content-type attribute; there is no content type for countersignatures.
1. signedAttributes字段不能包含内容类型属性；没有用于会签的内容类型。
2. The signedAttributes field MUST contain a message-digest attribute if it contains any other attributes.
2. 如果signedAttributes字段包含任何其他属性，则该字段必须包含消息摘要属性。
3. The input to the message-digesting process is the contents octets of the DER encoding of the signatureValue field of the SignerInfo value with which the attribute is associated.
3. 消息摘要处理的输入是属性关联的SignerInfo值的signatureValue字段的DER编码的内容八位字节。
A countersignature attribute can have multiple attribute values. The syntax is defined as a SET OF AttributeValue, and there MUST be one or more instances of AttributeValue present.
一个会签属性可以有多个属性值。语法定义为一组AttributeValue，必须存在一个或多个AttributeValue实例。
The UnsignedAttributes syntax is defined as a SET OF Attributes. The UnsignedAttributes in a signerInfo may include multiple instances of the countersignature attribute.
UnsignedAttributes语法定义为一组属性。signerInfo中的unsignedAttribute可能包含多个会签属性实例。
A countersignature, since it has type SignerInfo, can itself contain a countersignature attribute. Thus, it is possible to construct an arbitrarily long series of countersignatures.
由于副署具有SignerInfo类型，因此它本身可以包含副署属性。因此，可以构造任意长系列的会签。
Section 12.1 contains the ASN.1 module for the CMS, and Section 12.2 contains the ASN.1 module for the Version 1 Attribute Certificate.
第12.1节包含CMS的ASN.1模块，第12.2节包含版本1属性证书的ASN.1模块。
CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
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.
-- 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.
IMPORTS
进口
-- Imports from RFC 5280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from RFC 5280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttributeCertificate
FROM PKIXAttributeCertificate
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) attribute-cert(12) }
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttributeCertificate
FROM PKIXAttributeCertificate
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) attribute-cert(12) }
-- Imports from Appendix B of this document
AttributeCertificateV1
FROM AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
v1AttrCert(15) } ;
-- Imports from Appendix B of this document
AttributeCertificateV1
FROM AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
v1AttrCert(15) } ;
-- Cryptographic Message Syntax
--加密消息语法
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
AttributeValue ::= ANY
SignatureValue ::= OCTET STRING
SignatureValue ::= OCTET STRING
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientInfo,
ori [4] OtherRecipientInfo }
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientInfo,
ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING
EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING
SubjectKeyIdentifier ::= OCTET STRING
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
Digest ::= OCTET STRING
Digest ::= OCTET STRING
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING
MessageAuthenticationCode ::= OCTET STRING
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat }
AttributeCertificateV2 ::= AttributeCertificate
AttributeCertificateV2 ::= AttributeCertificate
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat }
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat }
CertificateSet ::= SET OF CertificateChoices
CertificateSet ::= SET OF CertificateChoices
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
UserKeyingMaterial ::= OCTET STRING
UserKeyingMaterial ::= OCTET STRING
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
-- Content Type Object Identifiers
--内容类型对象标识符
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }
-- The CMS Attributes
--CMS属性
MessageDigest ::= OCTET STRING
MessageDigest ::= OCTET STRING
SigningTime ::= Time
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
Countersignature ::= SignerInfo
Countersignature ::= SignerInfo
-- Attribute Object Identifiers
--属性对象标识符
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
-- Obsolete Extended Certificate syntax from PKCS #6
--PKCS#6中过时的扩展证书语法
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate }
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate }
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
Signature ::= BIT STRING
Signature ::= BIT STRING
END -- of CryptographicMessageSyntax2004
完--2004年加密信息SYNTAX的发布
AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All
--全部出口
IMPORTS
进口
-- Imports from RFC 5280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Attribute, CertificateSerialNumber,
Extensions, UniqueIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from RFC 5280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Attribute, CertificateSerialNumber,
Extensions, UniqueIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from RFC 5280 [PROFILE], Appendix A.2
GeneralNames
FROM PKIX1Implicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-implicit(19) }
-- Imports from RFC 5280 [PROFILE], Appendix A.2
GeneralNames
FROM PKIX1Implicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-implicit(19) }
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttCertValidityPeriod, IssuerSerial
FROM PKIXAttributeCertificate
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) attribute-cert(12) } ;
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttCertValidityPeriod, IssuerSerial
FROM PKIXAttributeCertificate
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) attribute-cert(12) } ;
-- Definition extracted from X.509-1997 [X.509-97], but
-- different type names are used to avoid collisions.
-- Definition extracted from X.509-1997 [X.509-97], but
-- different type names are used to avoid collisions.
AttributeCertificateV1 ::= SEQUENCE {
acInfo AttributeCertificateInfoV1,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
AttributeCertificateV1 ::= SEQUENCE {
acInfo AttributeCertificateInfoV1,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
AttributeCertificateInfoV1 ::= SEQUENCE {
version AttCertVersionV1 DEFAULT v1,
subject CHOICE {
baseCertificateID [0] IssuerSerial,
-- associated with a Public Key Certificate
subjectName [1] GeneralNames },
-- associated with a name
issuer GeneralNames,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL }
AttributeCertificateInfoV1 ::= SEQUENCE {
version AttCertVersionV1 DEFAULT v1,
subject CHOICE {
baseCertificateID [0] IssuerSerial,
-- associated with a Public Key Certificate
subjectName [1] GeneralNames },
-- associated with a name
issuer GeneralNames,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL }
AttCertVersionV1 ::= INTEGER { v1(0) }
AttCertVersionV1 ::= INTEGER { v1(0) }
END -- of AttributeCertificateVersion1
结束--属性证书1的结束
[ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ACPROFILE]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[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月。
[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月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号一的规范（ASN.1），1988年。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), 1988.
[X.209-88]CCITT。建议X.209：抽象语法符号1（ASN.1）基本编码规则规范，1988年。
[X.501-88] CCITT. Recommendation X.501: The Directory - Models, 1988.
[X.501-88]CCITT。建议X.501：《车型目录》，1988年。
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework, 1988.
[X.509-88]CCITT。建议X.509：目录认证框架，1988年。
[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication Framework, 1997.
[X.509-97]ITU-T.建议X.509：目录认证框架，1997年。
[X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework, 2000.
[X.509-00]ITU-T.建议X.509：目录认证框架，2000年。
[CMS1] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS1]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[CMS2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[CMS2]Housley，R.，“加密消息语法（CMS）”，RFC 3369，2002年8月。
[CMS3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS3]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[CMSMSIG] Housley, R., "Cryptographic Message Syntax (CMS) Multiple Signer Clarification", RFC 4853, April 2007.
[CMSMSIG]Housley，R.，“加密消息语法（CMS）多签名者澄清”，RFC 4853，2007年4月。
[DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[DH-X9.42]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[MSAC] Microsoft Development Network (MSDN) Library, "Authenticode", April 2004 Release.
[MSAC]微软开发网络（MSDN）库，“Authenticode”，2004年4月发布。
[MSG2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[MSG2]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[MSG3] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG3]Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[MSG3.1] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG3.1]Ramsdell，B.，编辑，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[NEWPKCS#1]Kaliski，B.和J.Staddon，“PKCS#1:RSA加密规范2.0版”，RFC 2437，1998年10月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[PKCS#1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[PKCS#1]Kaliski，B.，“PKCS#1:RSA加密版本1.5”，RFC 2313，1998年3月。
[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.
[PKCS#6]RSA实验室。PKCS#6：扩展证书语法标准，版本1.5。1993年11月。
[PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[PKCS#7]Kaliski，B.，“PKCS#7:加密消息语法版本1.5”，RFC 2315，1998年3月。
[PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993.
[PKCS#9]RSA实验室。PKCS#9：选定属性类型，版本1.1。1993年11月。
[PWRI] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001.
[PWRI]Gutmann，P.，“基于密码的CMS加密”，RFC 321112001年12月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
The Cryptographic Message Syntax provides a method for digitally signing data, digesting data, encrypting data, and authenticating data.
加密消息语法提供了对数据进行数字签名、摘要数据、加密数据和验证数据的方法。
Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade.
实现必须保护签名者的私钥。签名者私钥的泄露允许伪装。
Implementations must protect the key management private key, the key-encryption key, and the content-encryption key. Compromise of the key management private key or the key-encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the content-encryption key may result in disclosure of the associated encrypted content.
实现必须保护密钥管理私钥、密钥加密密钥和内容加密密钥。密钥管理私钥或密钥加密密钥的泄露可能导致该密钥保护的所有内容被泄露。类似地，内容加密密钥的泄露可能导致相关加密内容的泄露。
Implementations must protect the key management private key and the message-authentication key. Compromise of the key management private key permits masquerade of authenticated data. Similarly, compromise of the message-authentication key may result in undetectable modification of the authenticated content.
实现必须保护密钥管理私钥和消息身份验证密钥。密钥管理私钥的泄露允许伪装经过身份验证的数据。类似地，消息认证密钥的泄露可能导致认证内容的不可检测的修改。
The key management technique employed to distribute message-authentication keys must itself provide data origin authentication; otherwise, the contents are delivered with integrity from an unknown source. Neither RSA [PKCS#1] [NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary data origin authentication when both the originator and recipient public keys are bound to appropriate identities in X.509 certificates.
用于分发消息身份验证密钥的密钥管理技术本身必须提供数据源身份验证；否则，内容将从未知来源完整地交付。RSA[PKCS#1][NEWPKCS#1]和短暂静态Diffie Hellman[DH-X9.42]均未提供必要的数据源身份验证。静态Diffie-Hellman[DH-X9.42]在发端人和接收方公钥都绑定到X.509证书中的适当身份时，提供了必要的数据源身份验证。
When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC; therefore, the contents could originate from any one of the parties.
当两个以上的参与方共享同一消息身份验证密钥时，不提供数据源身份验证。知道消息认证密钥的任何一方都可以计算有效的MAC；因此，内容可能来自任何一方。
Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), and padding. Also, the generation of public/private key pairs relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
实现必须随机生成内容加密密钥、消息身份验证密钥、初始化向量（IVs）和填充。此外，公钥/私钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 4086[随机]在这方面提供了重要的指导。
When using key-agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with Triple-DES using a 168-bit Triple-DES content-encryption key, and the content-encryption key is wrapped with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover the Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms.
使用密钥协商算法或以前分发的对称密钥加密密钥时，密钥加密密钥用于加密内容加密密钥。如果密钥加密和内容加密算法不同，则有效的安全性取决于两种算法中较弱的一种。例如，如果使用168位三重DES内容加密密钥使用三重DES加密内容，并且使用40位RC2密钥加密密钥使用RC2包装内容加密密钥，则最多提供40位保护。确定40位RC2密钥值的简单搜索可以恢复三重DES密钥，然后可以使用三重DES密钥解密内容。因此，实现者必须确保密钥加密算法与内容加密算法一样强大。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of algorithms that must be supported to change over time.
实现者应该意识到加密算法会随着时间的推移变得越来越弱。随着新密码分析技术的发展和计算性能的提高，破坏特定密码算法的工作因素将减少。因此，加密算法的实现应该是模块化的，允许随时插入新算法。也就是说，实现者应该为一组算法做好准备，这些算法必须随着时间的推移而改变。
The countersignature unsigned attribute includes a digital signature that is computed on the content signature value; thus, the countersigning process need not know the original signed content. This structure permits implementation efficiency advantages; however, this structure may also permit the countersigning of an inappropriate signature value. Therefore, implementations that perform countersignatures should either verify the original signature value prior to countersigning it (this verification requires processing of the original content), or implementations should perform countersigning in a context that ensures that only appropriate signature values are countersigned.
反签名未签名属性包括根据内容签名值计算的数字签名；因此，会签过程不需要知道原始签名内容。这种结构允许实现效率优势；但是，此结构也允许对不适当的签名值进行会签。因此，执行会签的实现应该在会签之前验证原始签名值（此验证需要处理原始内容），或者在确保只会签适当的签名值的上下文中执行会签。
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, Dave Solo, Paul Timmel, and Sean Turner for their efforts and support.
本文件是许多专业人士贡献的成果。我感谢IETF S/MIME工作组所有成员的辛勤工作。我特别感谢Rich Ankney、Simon Blake Wilson、Tim Dean、Steve Dusse、Carl Ellison、Peter Gutmann、Bob Jueneman、Stephen Henson、Paul Hoffman、Scott Hollenbeck、Don Johnson、Burt Kaliski、John Linn、John Pawling、Blake Ramsdell、Francois Rousseau、Jim Schaad、Dave Solo、Paul Timmel和Sean Turner的努力和支持。
I thank Tim Polk for his encouragement in advancing this specification along the standards maturity ladder. In addition, I thank Jan Vilhuber for the careful reading that resulted in RFC Errata 1744.
我感谢Tim Polk鼓励我沿着标准成熟度阶梯推进本规范。此外，我感谢Jan Vilhuber的仔细阅读，最终得出了RFC勘误表1744。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com