Network Working Group R. Housley
Request for Comments: 3369 RSA Laboratories
Obsoletes: 2630, 3211 August 2002
Category: Standards Track
Network Working Group R. Housley
Request for Comments: 3369 RSA Laboratories
Obsoletes: 2630, 3211 August 2002
Category: Standards Track
Cryptographic Message Syntax (CMS)
加密消息语法（CMS）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
本文档描述了加密消息语法（CMS）。此语法用于对任意消息内容进行数字签名、摘要、身份验证或加密。
Table of Contents
目录
1. Introduction ................................................ 3
1.1 Changes Since RFC 2630 ...................................... 3
1.2 Terminology ................................................. 4
2. General Overview ............................................ 4
3. General Syntax .............................................. 5
4. Data Content Type ........................................... 5
5. Signed-data Content Type .................................... 6
5.1 SignedData Type ............................................. 7
5.2 EncapsulatedContentInfo Type ................................ 9
5.2.1 Compatibility with PKCS #7 ................................ 9
5.3 SignerInfo Type ............................................. 11
5.4 Message Digest Calculation Process .......................... 13
5.5 Signature Generation Process ................................ 14
5.6 Signature Verification Process .............................. 14
6. Enveloped-data Content Type ................................. 14
6.1 EnvelopedData Type .......................................... 16
6.2 RecipientInfo Type .......................................... 18
6.2.1 KeyTransRecipientInfo Type ................................ 19
6.2.2 KeyAgreeRecipientInfo Type ................................ 20
6.2.3 KEKRecipientInfo Type ..................................... 22
1. Introduction ................................................ 3
1.1 Changes Since RFC 2630 ...................................... 3
1.2 Terminology ................................................. 4
2. General Overview ............................................ 4
3. General Syntax .............................................. 5
4. Data Content Type ........................................... 5
5. Signed-data Content Type .................................... 6
5.1 SignedData Type ............................................. 7
5.2 EncapsulatedContentInfo Type ................................ 9
5.2.1 Compatibility with PKCS #7 ................................ 9
5.3 SignerInfo Type ............................................. 11
5.4 Message Digest Calculation Process .......................... 13
5.5 Signature Generation Process ................................ 14
5.6 Signature Verification Process .............................. 14
6. Enveloped-data Content Type ................................. 14
6.1 EnvelopedData Type .......................................... 16
6.2 RecipientInfo Type .......................................... 18
6.2.1 KeyTransRecipientInfo Type ................................ 19
6.2.2 KeyAgreeRecipientInfo Type ................................ 20
6.2.3 KEKRecipientInfo Type ..................................... 22
6.2.4 PasswordRecipientInfo Type ................................ 23
6.2.5 OtherRecipientInfo Type ................................... 24
6.3 Content-encryption Process .................................. 24
6.4 Key-encryption Process ...................................... 25
7. Digested-data Content Type .................................. 25
8. Encrypted-data Content Type ................................. 26
9. Authenticated-data Content Type ............................. 27
9.1 AuthenticatedData Type ...................................... 28
9.2 MAC Generation .............................................. 29
9.3 MAC Verification ............................................ 31
10. Useful Types ................................................ 31
10.1 Algorithm Identifier Types ................................. 31
10.1.1 DigestAlgorithmIdentifier ................................ 31
10.1.2 SignatureAlgorithmIdentifier ............................. 32
10.1.3 KeyEncryptionAlgorithmIdentifier ......................... 32
10.1.4 ContentEncryptionAlgorithmIdentifier ..................... 32
10.1.5 MessageAuthenticationCodeAlgorithm ....................... 32
10.1.6 KeyDerivationAlgorithmIdentifier ......................... 33
10.2 Other Useful Types ......................................... 33
10.2.1 CertificateRevocationLists ............................... 33
10.2.2 CertificateChoices ....................................... 33
10.2.3 CertificateSet ........................................... 34
10.2.4 IssuerAndSerialNumber .................................... 34
10.2.5 CMSVersion ............................................... 35
10.2.6 UserKeyingMaterial ....................................... 35
10.2.7 OtherKeyAttribute ........................................ 35
11. Useful Attributes ........................................... 35
11.1 Content Type ............................................... 36
11.2 Message Digest ............................................. 36
11.3 Signing Time ............................................... 37
11.4 Countersignature ........................................... 39
12. ASN.1 Modules ............................................... 40
12.1 CMS ASN.1 Module ........................................... 40
12.2 Version 1 Attribute Certificate ASN.1 Module ............... 46
13. References .................................................. 47
14. Security Considerations ..................................... 48
15. Acknowledgments ............................................. 50
16. Author Address .............................................. 50
17. Full Copyright Statement .................................... 51
6.2.4 PasswordRecipientInfo Type ................................ 23
6.2.5 OtherRecipientInfo Type ................................... 24
6.3 Content-encryption Process .................................. 24
6.4 Key-encryption Process ...................................... 25
7. Digested-data Content Type .................................. 25
8. Encrypted-data Content Type ................................. 26
9. Authenticated-data Content Type ............................. 27
9.1 AuthenticatedData Type ...................................... 28
9.2 MAC Generation .............................................. 29
9.3 MAC Verification ............................................ 31
10. Useful Types ................................................ 31
10.1 Algorithm Identifier Types ................................. 31
10.1.1 DigestAlgorithmIdentifier ................................ 31
10.1.2 SignatureAlgorithmIdentifier ............................. 32
10.1.3 KeyEncryptionAlgorithmIdentifier ......................... 32
10.1.4 ContentEncryptionAlgorithmIdentifier ..................... 32
10.1.5 MessageAuthenticationCodeAlgorithm ....................... 32
10.1.6 KeyDerivationAlgorithmIdentifier ......................... 33
10.2 Other Useful Types ......................................... 33
10.2.1 CertificateRevocationLists ............................... 33
10.2.2 CertificateChoices ....................................... 33
10.2.3 CertificateSet ........................................... 34
10.2.4 IssuerAndSerialNumber .................................... 34
10.2.5 CMSVersion ............................................... 35
10.2.6 UserKeyingMaterial ....................................... 35
10.2.7 OtherKeyAttribute ........................................ 35
11. Useful Attributes ........................................... 35
11.1 Content Type ............................................... 36
11.2 Message Digest ............................................. 36
11.3 Signing Time ............................................... 37
11.4 Countersignature ........................................... 39
12. ASN.1 Modules ............................................... 40
12.1 CMS ASN.1 Module ........................................... 40
12.2 Version 1 Attribute Certificate ASN.1 Module ............... 46
13. References .................................................. 47
14. Security Considerations ..................................... 48
15. Acknowledgments ............................................. 50
16. Author Address .............................................. 50
17. Full Copyright Statement .................................... 51
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 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 working group [PROFILE].
CMS可以支持各种基于证书的密钥管理体系结构，例如PKIX工作组[PROFILE]定义的体系结构。
The CMS values are generated using ASN.1 [X.208-88], using BER-encoding [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 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate version 1 attribute certificate transfer, key agreement and symmetric key-encryption key techniques for key management.
CMS源自RFC 2315[PKCS#7]中规定的PKCS#7 1.5版。尽可能保持向后兼容性；然而，为了适应用于密钥管理的版本1属性证书传输、密钥协议和对称密钥加密密钥技术，需要进行更改。
This document obsoletes RFC 2630 [OLDCMS] 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. The use of version 1 attribute certificates is deprecated.
本文件淘汰了RFC 2630[OLDCMS]和RFC 3211[PWRI]。基于密码的密钥管理包含在CMS规范中，并指定了一种扩展机制，以支持新的密钥管理方案，而无需对CMS进行进一步更改。保留了与RFC 2630和RFC 3211的向后兼容性；但是，添加了版本2属性证书传输。不推荐使用版本1属性证书。
S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, are compatible with S/MIME v3 signatures [MSG], which are based on RFC 2630. However, there are some subtle compatibility issues with signatures using PKCS#7 version 1.5 and the CMS. These issues are discussed in section 5.2.1.
基于PKCS#7版本1.5的S/MIME v2签名[OLDMSG]与基于RFC 2630的S/MIME v3签名[MSG]兼容。但是，使用PKCS#7 1.5版和CMS的签名存在一些微妙的兼容性问题。第5.2.1节讨论了这些问题。
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 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.
本文档中未讨论特定的加密算法，但RFC 2630中讨论了这些算法。关于特定密码算法的讨论已移至单独的文件[CMSALG]。协议和算法规范的分离允许IETF独立更新每个文档。本规范不要求实现任何特定算法。相反，依赖CMS的协议应该为其环境选择合适的算法。可从[CMSALG]或其他地方选择算法。
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]中的说明进行解释。
2 General Overview
2一般概述
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编码的数据类型。
3 General Syntax
3一般语法
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类型不应是选项类型。
4 Data Content Type
4数据内容类型
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 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].
S/MIME使用id数据来标识MIME编码的内容。RFC 2311为S/MIME v2[OLDMSG]指定了此内容标识符的使用，RFC 2633为S/MIME v3[MSG]指定了此内容标识符的使用。
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 either by an issuer distinguished name along with an issuer-specific serial number or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer's certificate can be included in the SignedData certificates field.
收件人独立计算邮件摘要。此消息摘要和签名者的公钥用于验证签名值。签名者的公钥由颁发者可分辨名称和特定于颁发者的序列号引用，或由唯一标识包含公钥的证书的使用者密钥标识符引用。签名者的证书可以包含在SignedData certificates字段中。
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 CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists 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 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 (encapContentInfo eContentType is other than id-data) OR (any SignerInfo structures are version 3) THEN version MUST be 3 ELSE version MUST be 1
如果（存在证书）和（存在任何版本2属性证书），则版本必须为4，否则如果（（存在证书）和（存在任何版本1属性证书））或（encapContentInfo eContentType不是id数据）或（任何SignerinInfo结构是版本3），则版本必须为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 chains 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 chains 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 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.
证书是证书的集合。这组证书足以包含从公认的“根”或“顶级证书颁发机构”到signerInfos字段中所有签名者的链。证书数量可能超过必要数量，并且可能有足够的证书包含来自两个或多个独立顶级认证机构的链。如果预期接收人有获得必要证书的替代方法（例如，从以前的一组证书），则证书也可能少于必要的数量。可包括签名人的证书。强烈反对使用版本1属性证书。
crls is a collection of certificate revocation lists (CRLs). It is intended that the set contain information sufficient to determine whether or not the certificates in the certificates 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.
crls是证书吊销列表（CRL）的集合。该集合包含足以确定证书字段中的证书是否有效的信息，但不需要这样的对应关系。CRL可能比需要的多，也可能比需要的少。
signerInfos is a collection of per-signer information. There MAY be any number of elements in the collection, including zero. The details of the SignerInfo type are discussed in section 5.3. Since each signer can employ a digital signature technique and future specifications could update the syntax, all implementations MUST gracefully handle unimplemented versions of SignerInfo. Further, since all implementations will not support every possible signature algorithm, all implementations MUST gracefully handle unimplemented signature algorithms when they are encountered.
signerInfos是每个签名者信息的集合。集合中可能有任意数量的元素，包括零。第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.
在EncapseedContentInfo字段中可选地省略eContent可以构造“外部签名”。在外部签名的情况下，已签名数据内容类型中包含的EncapseedContentInfo值中不包含正在签名的内容。如果封装的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 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. 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 both S/MIME v2 and S/MIME v3, 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[OLDMSG]指定了相同的签名消息格式，而在RFC 2633中为S/MIME v3[MSG]指定了相同的签名消息格式。S/MIME v2将MIME内容封装在SignedData contentInfo内容任意字段中携带的数据类型（即八位字节字符串）中，S/MIME v3将MIME内容封装在SignedData encapContentInfo eContent八位字节字符串中。因此，在S/MIME v2和S/MIME v3中，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 [ESS] signed receipt 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, the following information MAY be included:
在创建SignedData内容类型时，可以使用以下策略实现与PKCS#7的向后兼容性，其中封装的内容未使用数据类型进行格式化。实现可以检查eContentType的值，然后根据对象标识符值调整eContent的预期DER编码。例如，为了支持Microsoft AuthentiCode，可以包括以下信息：
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 the X.509 subjectKeyIdentifier extension value.
sid指定签名者的证书（从而指定签名者的公钥）。收件人需要签名人的公钥来验证签名。SignerIdentifier为指定签名者的公钥提供了两种选择。issuerAndSerialNumber替代方案通过发行人的可分辨名称和证书序列号识别签名人的证书；subjectKeyIdentifier通过X.509 subjectKeyIdentifier扩展值标识签名者的证书。
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.
实现必须支持接收SignerIdentifier的issuerAndSerialNumber和subjectKeyIdentifier表单。生成SignerIdentifier时，实现可能支持其中一种形式（issuerAndSerialNumber或subjectKeyIdentifier）并始终使用它，或者实现可能任意混合使用这两种形式。
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 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.
digestAlgorithm标识签名者使用的消息摘要算法和任何相关参数。使用第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 three 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 CertificateRevocationLists OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists 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 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 present) OR (unprotectedAttrs is present) OR (any RecipientInfo structures are a version other than 0) THEN version is 2 ELSE version is 0
如果（（存在originatorInfo）和（存在任何版本2属性证书））或（任何RecipientInfo结构包括pwri）或（任何RecipientInfo结构包括ori），则版本为3，如果（存在originatorInfo）或（存在未受保护的TTR）或（任何RecipientInfo结构是0以外的版本）则版本为2，否则版本为0
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 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 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 content-encryption key is encrypted with the recipient's public key. 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 the X.509 subjectKeyIdentifier extension value. For recipient processing, implementations MUST support both of these alternatives for specifying the recipient's certificate; and for sender processing, implementations MUST support at least one of these alternatives.
rid指定发件人用于保护内容加密密钥的收件人的证书或密钥。RecipientIdentifier提供了两种方法来指定收件人的证书，从而指定收件人的公钥。收件人的证书必须包含密钥传输公钥。因此，包含密钥使用扩展的收件人X.509版本3证书必须声明密钥加密位。内容加密密钥使用收件人的公钥加密。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；subjectKeyIdentifier通过X.509 subjectKeyIdentifier扩展值标识收件人的证书。对于收件人处理，实现必须支持这两种方法来指定收件人的证书；对于发送方处理，实现必须至少支持其中一种选择。
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 the X.509 subjectKeyIdentifier extension value. 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 subjectKeyIdentifier扩展值标识发送方的证书，从而标识发送方的公钥。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 support recipient processing of 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 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
recipientEncryptedKeys包括收件人标识符和一个或多个收件人的加密密钥。KeyAgreentRecipientIdentifier是一个选项，有两个选项指定接收方的证书，从而指定接收方的公钥，发送方使用该公钥生成成对密钥加密密钥。收件人的证书必须包含密钥协议公钥。因此，包含密钥使用扩展的收件人X.509版本3证书必须声明密钥协议位。内容加密密钥在成对密钥加密密钥中加密。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；RecipientKeyIdentifier如下所述。encryptedKey是加密内容加密的结果
key in the pairwise key-encryption key generated using the key agreement algorithm. Implementations MUST support both alternatives for specifying the recipient's certificate.
使用密钥协商算法生成的成对密钥加密密钥中的密钥。实现必须支持指定收件人证书的两种备选方案。
The fields of type RecipientKeyIdentifier have the following meanings:
RecipientKeyIdentifier类型的字段具有以下含义：
subjectKeyIdentifier identifies the recipient's certificate by the X.509 subjectKeyIdentifier extension value.
subjectKeyIdentifier通过X.509 subjectKeyIdentifier扩展值标识收件人的证书。
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 version MUST be 2. If unprotectedAttrs is absent, then version MUST be 0.
version是语法版本号。如果存在未受保护的TTR，则版本必须为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
4. 发端人使用消息身份验证密钥计算内容上的MAC值。如果发起人正在验证内容之外的任何信息（见第9.2节），则
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."
对内容计算消息摘要，使用消息身份验证密钥对内容和其他信息的消息摘要进行身份验证，结果成为“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 version 2 attribute certificates are present)) THEN version is 1 ELSE version is 0
如果（（存在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 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 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 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八位字节字符串。只有包含encapContentInfo eContent八位字节字符串值的八位字节被输入到消息摘要算法，而不是标记或长度八位字节。这样做的优点是不需要预先知道被认证内容的长度。尽管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., HMAC). The object identifier, along with any parameters, that specifies the MAC algorithm employed by the
对MAC计算处理的输入包括上面定义的MAC输入数据和在recipientInfo结构中传送的认证密钥。MAC计算的细节取决于所采用的MAC算法（例如HMAC）。对象标识符以及任何参数，用于指定应用程序使用的MAC算法
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.
发起人在macAlgorithm字段中携带。发起者生成的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. Examples include RSA, DSA, and ECDSA. 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和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 CertificateRevocationLists type gives a set of certificate revocation lists (CRLs). 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 CRLs than necessary or there MAY be fewer CRLs than necessary.
CertificateJournalists类型提供一组证书吊销列表（CRL）。该集合包含足以确定与该集合关联的证书和属性证书是否被吊销的信息。但是，CRL可能比需要的多，也可能比需要的少。
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或属性证书撤销列表。所有这些列表都有一个共同的语法。
CRLs are specified in X.509 [X.509-97], and they are profiled for use in the Internet in RFC 3280 [PROFILE].
CRL在X.509[X.509-97]中有规定，并且在RFC 3280[PROFILE]中对其进行了分析，以供在互联网上使用。
The definition of CertificateList is taken from X.509.
证书列表的定义取自X.509。
CertificateRevocationLists ::= SET OF CertificateList
CertificateRevocationLists ::= SET OF CertificateList
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], or a version 2 X.509 attribute certificate (ACv2) [X.509-00]. 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].
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]中指定。
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 }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
The CertificateSet type provides a set of certificates. It is intended that the set be sufficient to contain chains 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 "chain" is outside the scope of this document. Some applications may impose upper limits on the length of a chain; others may enforce certain relationships between the subjects and issuers of certificates within a chain.
“链”的确切含义不在本文件范围内。某些应用可能会对链的长度施加上限；其他人可能会强制执行链中的主体和证书颁发者之间的某些关系。
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) }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }
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 3280 [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 [OLDCMS]. The attributes are not listed in any particular order.
本节定义了可用于签名数据、信封数据、加密数据或认证数据的属性。属性的语法与X.501[X.501-88]和RFC 3280[PROFILE]兼容。本节中定义的一些属性最初是在PKCS#9[PKCS#9]中定义的；其他最初在本规范的早期版本[OLDCMS]中定义。属性没有按任何特定顺序列出。
Additional attributes are defined in many places, notably the S/MIME Version 3 Message Specification [MSG] and the Enhanced Security Services for S/MIME [ESS], which also include recommendations on the placement of these attributes.
在许多地方定义了其他属性，特别是S/MIME版本3消息规范[MSG]和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 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. Midnight (GMT) MUST be represented as "YYMMDD000000Z". Century information is implicit, and the century MUST be determined as follows:
UTCTime值必须以格林尼治平均时间（Zulu）表示，并且必须包括秒（即时间为YYMMDDHHMMSZ），即使秒数为零。午夜（GMT）必须表示为“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 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
广义时间值必须以格林威治标准时间（Zulu）表示，并且必须包括秒（即，时间为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 DER encoding of the signatureValue field of a SignerInfo value in signed-data. Thus, the countersignature attribute type countersigns (signs in serial) another signature.
会签属性类型指定签名数据中SignerInfo值的signatureValue字段的DER编码的内容八位字节上的一个或多个签名。因此，会签属性类型会签（串行签名）另一个签名。
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模块。
CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }
CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }
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 3280 [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 3280 [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
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
ContentType ::= OBJECT IDENTIFIER
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists 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 CertificateRevocationLists OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists 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 }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
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
CertificateRevocationLists ::= SET OF CertificateList
CertificateRevocationLists ::= SET OF CertificateList
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
AttributeCertificateV2 ::= AttributeCertificate
AttributeCertificateV2 ::= AttributeCertificate
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) }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }
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 }
-- 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 }
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate }
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 CryptographicMessageSyntax
END--加密消息语法的结束
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 IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
--全部出口
IMPORTS
进口
-- Imports from RFC 3280 [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 3280 [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 3280 [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 3280 [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月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3269, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC32692002年8月。
[DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[DSS]国家标准与技术研究所。FIPS Pub 186：数字签名标准。1994年5月19日。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[OLDCMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[OLDMSG]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002.
[简介]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施：证书和CRL简介”，RFC 32802002年4月。
[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 S/MIME", RFC 3211, December 2001.
[PWRI]Gutmann，P.，“基于密码的S/MIME加密”，RFC 32111901年12月。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[随机]Eastlake，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[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：抽象语法符号1（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
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
用于分发消息身份验证密钥的密钥管理技术本身必须提供数据源身份验证，否则内容将从未知源完整地交付。RSA[PKCS#1，NEWPKCS#1]和短暂静态Diffie-Hellman[DH-X9.42]均未提供必要的数据源身份验证。静态微分Hellman[DH-X9.42]提供
the necessary data origin authentication when both the originator and recipient public keys are bound to appropriate identities in X.509 certificates.
当发送方和接收方公钥都绑定到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 a 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 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
实现必须随机生成内容加密密钥、消息身份验证密钥、初始化向量（IVs）和填充。此外，公钥/私钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 1750[RANDOM]在这方面提供了重要的指导，FIPS Pub 186[DSS]的附录3提供了一种高质量的PRNG技术。
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, implementors 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, and Dave Solo 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的努力和支持。
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: rhousley@rsasecurity.com
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：rhousley@rsasecurity.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。