Network Working Group R. Housley
Request for Comments: 2630 SPYRUS
Category: Standards Track June 1999
Network Working Group R. Housley
Request for Comments: 2630 SPYRUS
Category: Standards Track June 1999
Cryptographic Message Syntax
加密消息语法
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
本文档描述加密消息语法。此语法用于对任意消息进行数字签名、摘要、身份验证或加密。
The Cryptographic Message Syntax 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 attribute certificate transfer and key agreement techniques for key management.
加密消息语法源自RFC 2315[PKCS#7]中规定的PKCS#7版本1.5。尽可能保持向后兼容性；然而，为了适应用于密钥管理的属性证书传输和密钥协商技术，需要进行更改。
Table of Contents
目录
1 Introduction ................................................. 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 ............................ 8
5.3 SignerInfo Type ......................................... 9
5.4 Message Digest Calculation Process ...................... 11
5.5 Message Signature Generation Process .................... 12
5.6 Message Signature Verification Process .................. 12
6 Enveloped-data Content Type .................................. 12
6.1 EnvelopedData Type ...................................... 14
6.2 RecipientInfo Type ...................................... 15
6.2.1 KeyTransRecipientInfo Type ....................... 16
6.2.2 KeyAgreeRecipientInfo Type ....................... 17
6.2.3 KEKRecipientInfo Type ............................ 19
6.3 Content-encryption Process .............................. 20
6.4 Key-encryption Process .................................. 20
7 Digested-data Content Type ................................... 21
8 Encrypted-data Content Type .................................. 22
9 Authenticated-data Content Type .............................. 23
9.1 AuthenticatedData Type .................................. 23
9.2 MAC Generation .......................................... 25
9.3 MAC Verification ........................................ 26
10 Useful Types ................................................. 27
10.1 Algorithm Identifier Types ............................. 27
10.1.1 DigestAlgorithmIdentifier ...................... 27
10.1.2 SignatureAlgorithmIdentifier ................... 27
10.1.3 KeyEncryptionAlgorithmIdentifier ............... 28
10.1.4 ContentEncryptionAlgorithmIdentifier ........... 28
10.1.5 MessageAuthenticationCodeAlgorithm ............. 28
10.2 Other Useful Types ..................................... 28
10.2.1 CertificateRevocationLists ..................... 28
10.2.2 CertificateChoices ............................. 29
10.2.3 CertificateSet ................................. 29
10.2.4 IssuerAndSerialNumber .......................... 30
10.2.5 CMSVersion ..................................... 30
10.2.6 UserKeyingMaterial ............................. 30
10.2.7 OtherKeyAttribute .............................. 30
1 Introduction ................................................. 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 ............................ 8
5.3 SignerInfo Type ......................................... 9
5.4 Message Digest Calculation Process ...................... 11
5.5 Message Signature Generation Process .................... 12
5.6 Message Signature Verification Process .................. 12
6 Enveloped-data Content Type .................................. 12
6.1 EnvelopedData Type ...................................... 14
6.2 RecipientInfo Type ...................................... 15
6.2.1 KeyTransRecipientInfo Type ....................... 16
6.2.2 KeyAgreeRecipientInfo Type ....................... 17
6.2.3 KEKRecipientInfo Type ............................ 19
6.3 Content-encryption Process .............................. 20
6.4 Key-encryption Process .................................. 20
7 Digested-data Content Type ................................... 21
8 Encrypted-data Content Type .................................. 22
9 Authenticated-data Content Type .............................. 23
9.1 AuthenticatedData Type .................................. 23
9.2 MAC Generation .......................................... 25
9.3 MAC Verification ........................................ 26
10 Useful Types ................................................. 27
10.1 Algorithm Identifier Types ............................. 27
10.1.1 DigestAlgorithmIdentifier ...................... 27
10.1.2 SignatureAlgorithmIdentifier ................... 27
10.1.3 KeyEncryptionAlgorithmIdentifier ............... 28
10.1.4 ContentEncryptionAlgorithmIdentifier ........... 28
10.1.5 MessageAuthenticationCodeAlgorithm ............. 28
10.2 Other Useful Types ..................................... 28
10.2.1 CertificateRevocationLists ..................... 28
10.2.2 CertificateChoices ............................. 29
10.2.3 CertificateSet ................................. 29
10.2.4 IssuerAndSerialNumber .......................... 30
10.2.5 CMSVersion ..................................... 30
10.2.6 UserKeyingMaterial ............................. 30
10.2.7 OtherKeyAttribute .............................. 30
11 Useful Attributes ............................................ 31
11.1 Content Type ........................................... 31
11.2 Message Digest ......................................... 32
11.3 Signing Time ........................................... 32
11.4 Countersignature ....................................... 34
12 Supported Algorithms ......................................... 35
12.1 Digest Algorithms ...................................... 35
12.1.1 SHA-1 .......................................... 35
12.1.2 MD5 ............................................ 35
12.2 Signature Algorithms ................................... 36
12.2.1 DSA ............................................ 36
12.2.2 RSA ............................................ 36
12.3 Key Management Algorithms .............................. 36
12.3.1 Key Agreement Algorithms ....................... 36
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman. 37
12.3.2 Key Transport Algorithms ....................... 38
12.3.2.1 RSA .................................. 39
12.3.3 Symmetric Key-Encryption Key Algorithms ........ 39
12.3.3.1 Triple-DES Key Wrap .................. 40
12.3.3.2 RC2 Key Wrap ......................... 41
12.4 Content Encryption Algorithms ........................... 41
12.4.1 Triple-DES CBC .................................. 42
12.4.2 RC2 CBC ......................................... 42
12.5 Message Authentication Code Algorithms .................. 42
12.5.1 HMAC with SHA-1 ................................. 43
12.6 Triple-DES and RC2 Key Wrap Algorithms .................. 43
12.6.1 Key Checksum .................................... 44
12.6.2 Triple-DES Key Wrap ............................. 44
12.6.3 Triple-DES Key Unwrap ........................... 44
12.6.4 RC2 Key Wrap .................................... 45
12.6.5 RC2 Key Unwrap .................................. 46
Appendix A: ASN.1 Module ........................................ 47
References ....................................................... 55
Security Considerations .......................................... 56
Acknowledgments .................................................. 58
Author's Address ................................................. 59
Full Copyright Statement ......................................... 60
11 Useful Attributes ............................................ 31
11.1 Content Type ........................................... 31
11.2 Message Digest ......................................... 32
11.3 Signing Time ........................................... 32
11.4 Countersignature ....................................... 34
12 Supported Algorithms ......................................... 35
12.1 Digest Algorithms ...................................... 35
12.1.1 SHA-1 .......................................... 35
12.1.2 MD5 ............................................ 35
12.2 Signature Algorithms ................................... 36
12.2.1 DSA ............................................ 36
12.2.2 RSA ............................................ 36
12.3 Key Management Algorithms .............................. 36
12.3.1 Key Agreement Algorithms ....................... 36
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman. 37
12.3.2 Key Transport Algorithms ....................... 38
12.3.2.1 RSA .................................. 39
12.3.3 Symmetric Key-Encryption Key Algorithms ........ 39
12.3.3.1 Triple-DES Key Wrap .................. 40
12.3.3.2 RC2 Key Wrap ......................... 41
12.4 Content Encryption Algorithms ........................... 41
12.4.1 Triple-DES CBC .................................. 42
12.4.2 RC2 CBC ......................................... 42
12.5 Message Authentication Code Algorithms .................. 42
12.5.1 HMAC with SHA-1 ................................. 43
12.6 Triple-DES and RC2 Key Wrap Algorithms .................. 43
12.6.1 Key Checksum .................................... 44
12.6.2 Triple-DES Key Wrap ............................. 44
12.6.3 Triple-DES Key Unwrap ........................... 44
12.6.4 RC2 Key Wrap .................................... 45
12.6.5 RC2 Key Unwrap .................................. 46
Appendix A: ASN.1 Module ........................................ 47
References ....................................................... 55
Security Considerations .......................................... 56
Acknowledgments .................................................. 58
Author's Address ................................................. 59
Full Copyright Statement ......................................... 60
1 Introduction
1导言
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
本文档描述加密消息语法。此语法用于对任意消息进行数字签名、摘要、身份验证或加密。
The Cryptographic Message Syntax describes an encapsulation syntax for data protection. It supports digital signatures, message authentication codes, and encryption. The syntax allows multiple encapsulation, so 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.
加密消息语法描述用于数据保护的封装语法。它支持数字签名、消息身份验证代码和加密。该语法允许多个封装，因此一个封装信封可以嵌套在另一个封装信封中。同样，一方可以对一些先前封装的数据进行数字签名。它还允许将任意属性（如签名时间）与消息内容一起签名，并提供与签名关联的其他属性（如反签名）。
The Cryptographic Message Syntax can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX working group.
加密消息语法可以支持各种基于证书的密钥管理体系结构，例如PKIX工作组定义的体系结构。
The Cryptographic Message Syntax 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.
加密消息语法值是使用ASN.1[X.208-88]和BER编码[X.209-88]生成的。值通常表示为八位字节字符串。虽然许多系统能够可靠地传输任意八位字节字符串，但众所周知，许多电子邮件系统不能。本文件不涉及八位字节字符串编码机制，以便在此类环境中可靠传输。
2 General Overview
2一般概述
The Cryptographic Message Syntax (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 if desired.
符合此规范的实现必须实现保护内容、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-
作为一般设计理念，每种内容类型都允许使用不定长基本编码规则（BER）编码进行单遍处理。如果内容较大、存储在磁带上或从另一个进程“管道”传输，则单程操作尤其有用。单身-
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 require DER encoding. Signed attributes and authenticated attributes must 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 CMS data types that require DER encoding.
pass操作有一个显著的缺点：很难在一次pass中使用可分辨编码规则（DER）[X.509-88]编码执行编码操作，因为各种组件的长度可能事先未知。但是，签名数据内容类型中的签名属性和认证数据内容类型中的认证属性需要DER编码。必须以DER格式传输已签名属性和已验证属性，以确保收件人可以验证包含一个或多个未识别属性的内容。签名属性和认证属性是唯一需要DER编码的CMS数据类型。
3 General Syntax
3一般语法
The Cryptographic Message Syntax (CMS) associates a content type identifier with a content. The syntax shall 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
数据内容类型旨在指任意八位字符串，如ASCII文本文件；解释权留给应用程序。这样的字符串不需要任何内部结构
(although they could have their own ASN.1 definition or other structure).
（尽管它们可以有自己的ASN.1定义或其他结构）。
The data content type is generally encapsulated in the signed-data, enveloped-data, digested-data, encrypted-data, or authenticated-data content type.
数据内容类型通常封装在签名数据、信封数据、摘要数据、加密数据或认证数据内容类型中。
5 Signed-data Content Type
5签名数据内容类型
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 may 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. If no attribute certificates are present in the certificates field, the encapsulated content type is id-data, and all of the elements of SignerInfos are version 1, then the value of version shall be 1. Alternatively, if attribute certificates are present, the encapsulated content type is other than id-data, or any of the elements of SignerInfos are version 3, then the value of version shall be 3.
version是语法版本号。如果证书字段中不存在属性证书，封装的内容类型为id数据，且SignerInfos的所有元素均为版本1，则版本的值应为1。或者，如果存在属性证书，封装的内容类型不是id数据，或者SignerInfos的任何元素是版本3，则版本的值应为3。
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. 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). As discussed above, if attribute certificates are present, then the value of version shall be 3.
证书是证书的集合。这组证书足以包含从公认的“根”或“顶级证书颁发机构”到signerInfos字段中所有签名者的链。证书数量可能超过必要数量，并且可能有足够的证书包含来自两个或多个独立顶级认证机构的链。如果预期接收人有获得必要证书的替代方法（例如，从以前的一组证书），则证书也可能少于必要的数量。如上所述，如果存在属性证书，则版本的值应为3。
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.
signerInfos是每个签名者信息的集合。集合中可能有任意数量的元素，包括零。第5.3节讨论了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 that 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" should be id-data (as defined in section 4), and the content field of the EncapsulatedContentInfo value should be omitted.
在没有签名者的退化情况下，被“签名”的封装ContentInfo值是不相关的。在这种情况下，被“签名”的封装ContentInfo值内的内容类型应该是id数据（如第4节中所定义），并且应该省略封装ContentInfo值的内容字段。
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 shall be 1. If
version是语法版本号。如果签名者是选择发布者和序列号，则版本应为1。如果
the SignerIdentifier is subjectKeyIdentifier, then the version shall be 3.
签名者为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扩展值标识签名者的证书。
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.
digestAlgorithm标识签名者使用的消息摘要算法和任何相关参数。使用第5.4节中描述的过程，根据正在签名的内容或内容以及签名的属性计算消息摘要。消息摘要算法应在相关SignerData的digestAlgorithms字段中列出。
signedAttributes 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. Each SignedAttribute in the SET must be DER 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:
SignedAttribute是已签名属性的集合。该字段是可选的，但如果要签名的En封装ContentInfo值的内容类型不是id数据，则该字段必须存在。集合中的每个SignedAttribute都必须进行顺序编码。第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. The content-type attribute is not required when 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.
签名是使用消息摘要和签名者的私钥生成数字签名的结果。
unsignedAttributes is a collection of attributes that are not signed. The field is optional. Useful attribute types, such as countersignatures, are defined in Section 11.
unsignedAttributes是未签名属性的集合。该字段是可选的。第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.
attrValues是组成属性的一组值。集合中每个值的类型可以由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 signedAttributes 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 SignedAttributes value contained in the signedAttributes field. Since the SignedAttributes value, when present, must contain the content type and the content message digest attributes, those values are indirectly included in the result. The content type attribute is not required when used as part of a countersignature unsigned attribute as defined in section 11.4. A separate encoding of the signedAttributes field is performed for message digest calculation. The IMPLICIT [0] tag in the signedAttributes 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 [0] tag, is to be included in the message digest calculation along with the length and content octets of the SignedAttributes value.
消息摘要计算过程的结果取决于SignedAttribute字段是否存在。当字段不存在时，结果就是如上所述的内容的消息摘要。但是，当该字段存在时，结果是SignedAttribute字段中包含的SignedAttribute值的完整DER编码的消息摘要。由于SignedAttributes值（如果存在）必须包含内容类型和内容消息摘要属性，因此这些值将间接包含在结果中。内容类型属性在用作第11.4节中定义的副署无符号属性的一部分时不需要。对signedAttributes字段执行单独的编码以进行消息摘要计算。signedAttributes字段中的隐式[0]标记不用于DER编码，而是使用一组显式标记。也就是说，标记集的DER编码，而不是隐式[0]标记的DER编码，将与SignedAttribute值的长度和内容八位字节一起包含在消息摘要计算中。
When the signedAttributes field is absent, then 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.
如果缺少signedAttributes字段，则只有包含signedData encapContentInfo eContent八位元字符串值的八位元（例如，文件内容）被输入到消息摘要计算中。这具有这样的优点，即在签名生成过程之前不需要知道被签名的内容的长度。
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 messages 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 is 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 may 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属性的值相同。
6 Enveloped-data Content Type
6信封数据内容类型
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 three 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; and
密钥协议：使用接收方的公钥和发送方的私钥生成成对对称密钥，然后在成对对称密钥中加密内容加密密钥；和
symmetric key-encryption keys: the content-encryption key is encrypted in a previously distributed symmetric key-encryption key.
对称密钥加密密钥：内容加密密钥在以前分发的对称密钥加密密钥中加密。
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 OF RecipientInfo
RecipientInfos ::= SET 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. If originatorInfo is present, then version shall be 2. If any of the RecipientInfo structures included have a version other than 0, then the version shall be 2. If unprotectedAttrs is present, then version shall be 2. If originatorInfo is absent, all of the RecipientInfo structures are version 0, and unprotectedAttrs is absent, then version shall be 0.
version是语法版本号。如果存在originatorInfo，则版本应为2。如果包含的任何RecipientInfo结构的版本不是0，则版本应为2。如果存在未受保护的TTR，则版本应为2。如果缺少originatorInfo，则所有RecipientInfo结构都是版本0，并且缺少未受保护的TTR，则版本应为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 to make chains from a recognized "root" or "top-level certification authority" to all recipients. However, certs may contain more certificates than necessary, and there may be certificates sufficient to make chains 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 is 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 the three key management
每个收件人的信息在RecipientInfo类型中表示。RecipientInfo对三个密钥管理具有不同的格式
techniques that are supported: key transport, key agreement, and previously distributed symmetric key-encryption keys. Any of the three key management techniques can be used for each recipient of the same encrypted content. In all cases, the content-encryption key is transferred to one or more recipient in encrypted form.
支持的技术：密钥传输、密钥协商和以前分发的对称密钥加密密钥。三种密钥管理技术中的任何一种都可以用于相同加密内容的每个收件人。在所有情况下，内容加密密钥都以加密形式传输给一个或多个收件人。
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo }
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo }
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 shall be 0. If the RecipientIdentifier is subjectKeyIdentifier, then the version shall 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. 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.
rid指定发件人用于保护内容加密密钥的收件人的证书或密钥。RecipientIdentifier提供了两种方法来指定收件人的证书，从而指定收件人的公钥。收件人的证书必须包含密钥传输公钥。内容加密密钥使用收件人的公钥加密。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；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 recipient that uses 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 shall 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. Permitting originator anonymity since the public key is not certified.
发起者是一个选择，有三个选项指定发送者的密钥协议公钥。发送方使用相应的私钥和接收方的公钥生成成对密钥。内容加密密钥在成对密钥中加密。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.
ukm是可选的。通过一些密钥协商算法，发送方提供用户密钥材料（UKM），以确保每次相同的双方生成成对密钥时生成不同的密钥。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the content-encryption key in 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. 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 key in the pairwise key-encryption key generated using the key agreement algorithm.
recipientEncryptedKeys包括收件人标识符和一个或多个收件人的加密密钥。KeyAgreentRecipientIdentifier是一个选项，有两个选项指定接收方的证书，从而指定接收方的公钥，发送方使用该公钥生成成对密钥加密密钥。收件人的证书必须包含密钥协议公钥。内容加密密钥在成对密钥加密密钥中加密。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；RecipientKeyIdentifier如下所述。encryptedKey是对使用密钥协商算法生成的成对密钥加密密钥中的内容加密密钥进行加密的结果。
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 shall 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.
另一个是可选的。如果存在，此字段包含收件人用于确定发件人使用的密钥加密密钥的其他信息。
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八位字节字符串中。
The input to the content-encryption process is the "value" of the content being enveloped. Only the value octets of the envelopedData encryptedContentInfo encryptedContent OCTET STRING are encrypted; the OCTET STRING tag and length octets are not encrypted.
内容加密过程的输入是被封装内容的“值”。仅加密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 three key management techniques can be used for each recipient of the same encrypted content.
三种密钥管理技术中的任何一种都可以用于相同加密内容的每个收件人。
7 Digested-data Content Type
7摘要数据内容类型
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 shall be 0; however, if the encapsulated content type is other than id-data, then the value of version shall be 2.
version是语法版本号。如果封装内容类型为id数据，则版本值为0；但是，如果封装的内容类型不是id数据，则版本的值应为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值。
8 Encrypted-data Content Type
8加密数据内容类型
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 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 shall be 2. If unprotectedAttrs is absent, then version shall 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节定义了有用的属性类型。
9 Authenticated-data Content Type
9已验证的数据内容类型
The authenticated-data content type consists of content of any type, a message authentication code (MAC), and encrypted authentication keys for one or more recipients. The combination of the MAC and one encrypted authentication key for a recipient is necessary for that recipient to verify the integrity of the content. Any type of content can be integrity protected for an arbitrary number of recipients.
经过身份验证的数据内容类型包括任何类型的内容、消息身份验证码（MAC）和一个或多个收件人的加密身份验证密钥。MAC和收件人的一个加密身份验证密钥的组合对于该收件人验证内容的完整性是必要的。任何类型的内容都可以为任意数量的收件人提供完整性保护。
The process by which authenticated-data is constructed involves the following steps:
构造经过身份验证的数据的过程包括以下步骤：
1. A message-authentication key for a particular message-authentication algorithm is generated at random.
1. 随机生成特定消息认证算法的消息认证密钥。
2. The message-authentication key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used.
2. 为每个收件人加密邮件身份验证密钥。此加密的详细信息取决于所使用的密钥管理算法。
3. For each recipient, the encrypted message-authentication key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2.
3. 对于每个收件人，加密的邮件身份验证密钥和其他特定于收件人的信息被收集到第6.2节中定义的RecipientInfo值中。
4. Using the message-authentication key, the originator computes a MAC value on the content. If the originator is authenticating any information in addition to the content (see Section 9.2), a message digest is calculated on the content, the message digest of the content and the other information are authenticated using the message-authentication key, and the result becomes the "MAC value."
4. 发端人使用消息身份验证密钥计算内容上的MAC值。如果发端人正在验证除内容外的任何信息（见第9.2节），则在内容上计算消息摘要，使用消息验证密钥验证内容和其他信息的消息摘要，结果成为“MAC值”
The following object identifier identifies the authenticated-data content type:
以下对象标识符标识经过身份验证的数据内容类型：
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
The authenticated-data content type shall have ASN.1 type AuthenticatedData:
认证数据内容类型应具有ASN.1类型认证数据：
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthenticatedAttributes [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. It shall be 0.
version是语法版本号。它应该是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 authenticatedAttributes field must also be present.
digestAlgorithm标识消息摘要算法和任何相关参数，如果存在经过身份验证的属性，则用于计算封装内容上的消息摘要。第9.2节描述了消息摘要处理过程。digestAlgorithm字段的放置有助于收件人进行一次性处理。如果digestAlgorithm字段存在，则authenticatedAttributes字段也必须存在。
encapContentInfo is the content that is authenticated, as defined in section 5.2.
encapContentInfo是第5.2节中定义的经过身份验证的内容。
authenticatedAttributes is a collection of authenticated attributes. The authenticatedAttributes structure is optional, but it must be present if the content type of the EncapsulatedContentInfo value being authenticated is not id-data. If the authenticatedAttributes field is present, then the digestAlgorithm field must also be present. Each AuthenticatedAttribute in the SET must be DER encoded. Useful attribute types are defined in Section 11. If the authenticatedAttributes field is present, it must contain, at a minimum, the following two attributes:
authenticatedAttributes是已验证属性的集合。authenticatedAttributes结构是可选的，但如果要验证的封装ContentInfo值的内容类型不是id数据，则它必须存在。如果存在authenticatedAttributes字段，则digestAlgorithm字段也必须存在。集合中的每个AuthenticatedAttribute都必须进行DER编码。第11节定义了有用的属性类型。如果存在authenticatedAttributes字段，则它必须至少包含以下两个属性：
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是消息身份验证代码。
unauthenticatedAttributes 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.
unauthenticatedAttributes是未经身份验证的属性的集合。该字段是可选的。到目前为止，尚未定义任何属性用作未经验证的属性，但第11节中定义了其他有用的属性类型。
The MAC calculation process computes a message authentication code (MAC) on either the message being authenticated or a message digest of message being authenticated together with the originator's authenticated attributes.
MAC计算过程在正在被认证的消息或正在被认证的消息的消息摘要上计算消息认证码（MAC）以及发起人的认证属性。
If authenticatedAttributes 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.
如果缺少authenticatedAttributes字段，则MAC计算过程的输入是encapContentInfo eContent八位字符串的值。只有包含eContent八位元字符串值的八位元被输入到MAC算法；省略标记和长度八位字节。这具有这样的优点，即在MAC生成过程之前不需要知道被认证的内容的长度。
If authenticatedAttributes 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
如果存在authenticatedAttributes字段，则必须包括内容类型属性（如第11.1节所述）和消息摘要属性（如第11.2节所述），并且MAC计算过程的输入为DER编码
authenticatedAttributes. A separate encoding of the authenticatedAttributes field is performed for message digest calculation. The IMPLICIT [2] tag in the authenticatedAttributes 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 authenticatedAttributes value.
身份验证属性。authenticatedAttributes字段的单独编码用于消息摘要计算。authenticatedAttributes字段中的隐式[2]标记不用于DER编码，而是使用一组显式标记。也就是说，标签集而不是隐式[2]标签的DER编码将与authenticatedAttributes值的长度和内容八位字节一起包括在消息摘要计算中。
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 messages 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 originator is carried in the macAlgorithm field. The MAC value generated by the originator is encoded as an OCTET STRING and carried in the mac field.
对MAC计算处理的输入包括上面定义的MAC输入数据和在recipientInfo结构中传送的认证密钥。MAC计算的细节取决于所采用的MAC算法（例如HMAC）。macAlgorithm字段中包含指定发起人采用的MAC算法的对象标识符以及任何参数。发起者生成的MAC值被编码为八位字节字符串，并携带在MAC字段中。
The input to the MAC verification process includes the input data (determined based on the presence or absence of the authenticatedAttributes 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中定义的authenticatedAttributes字段的存在与否确定）和recipientInfo中传递的认证密钥。MAC验证过程的细节取决于所采用的MAC算法。
The recipient may 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 authenticatedAttributes is authenticated as described in section 9.2. For authentication to succeed, the message MAC value calculated by the recipient must be
收件人不得依赖发端人计算的任何MAC值或消息摘要值。内容按照第9.2节所述进行认证。如果发起人包括认证属性，则认证属性的内容按照第9.2节所述进行认证。要使身份验证成功，收件人计算的消息MAC值必须为
the same as the value of the mac field. Similarly, for authentication to succeed when the authenticatedAttributes field is present, the content message digest value calculated by the recipient must be the same as the message digest value included in the authenticatedAttributes message-digest attribute.
与mac字段的值相同。类似地，要在authenticatedAttributes字段存在时成功进行身份验证，收件人计算的内容消息摘要值必须与authenticatedAttributes消息摘要属性中包含的消息摘要值相同。
10 Useful Types
10种有用的类型
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 imported from X.509 [X.509-88].
所有算法标识符都具有相同的类型：AlgorithmIdentifier。算法识别器的定义从X.509[X.509-88]导入。
There are many alternatives for each type of algorithm listed. For each of these five types, Section 12 lists the algorithms that must be included in a CMS implementation.
对于列出的每种类型的算法，都有许多备选方案。对于这五种类型中的每一种，第12节列出了CMS实现中必须包含的算法。
The DigestAlgorithmIdentifier type identifies a message-digest algorithm. Examples include SHA-1, MD2, and MD5. A message-digest algorithm maps an octet string (the message) 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 DSS and RSA. 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类型标识签名算法。示例包括DSS和RSA。签名算法支持签名生成和验证操作。签名生成操作使用消息摘要和签名者的私钥生成签名值。签名验证操作使用消息摘要和签名者的公钥来确定签名值是否有效。上下文确定要执行的操作。
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, and previously distributed symmetric key-encrypting keys 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 message) 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. 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。MAC算法支持生成和验证操作。MAC生成和验证操作使用相同的对称密钥。上下文确定要执行的操作。
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= 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
CertificateJournalists类型提供一组证书吊销列表（CRL）。该集合包含足以确定证书和
attribute certificates with which the set is associated are revoked or not. However, there may be more CRLs than necessary or there may be fewer CRLs than necessary.
与集合关联的属性证书是否已吊销。但是，CRL可能比需要的多，也可能比需要的少。
The CertificateList may contain a CRL, an Authority Revocation List (ARL), a Delta Revocation List, or an Attribute Certificate Revocation List. All of these lists share a common syntax.
证书列表可以包含CRL、授权撤销列表（ARL）、增量撤销列表或属性证书撤销列表。所有这些列表都有一个共同的语法。
CRLs are specified in X.509 [X.509-97], and they are profiled for use in the Internet in RFC 2459 [PROFILE].
CRL在X.509[X.509-97]中有规定，并在RFC 2459[PROFILE]中对其进行了分析，以供在互联网上使用。
The definition of CertificateList is imported from X.509.
CertificateList的定义是从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, or an X.509 attribute certificate [X.509-97]. The PKCS #6 extended certificate is obsolete. PKCS #6 certificates are included for backward compatibility, and their use should be avoided. The Internet profile of X.509 certificates is specified in the "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE].
CertificateChoices类型提供PKCS#6扩展证书[PKCS#6]、X.509证书或X.509属性证书[X.509-97]。PKCS#6扩展证书已过时。PKCS#6证书用于向后兼容，应避免使用它们。X.509证书的Internet配置文件在“Internet X.509公钥基础设施：证书和CRL配置文件”[配置文件]中指定。
The definitions of Certificate and AttributeCertificate are imported from X.509.
证书和属性证书的定义从X.509导入。
CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57
CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57
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 imported from X.501 [X.501-88], and the definition of CertificateSerialNumber is imported from X.509 [X.509-97].
名称的定义从X.501[X.501-88]导入，证书SerialNumber的定义从X.509[X.509-97]导入。
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber ::= INTEGER
The Version type gives a syntax version number, for compatibility with future revisions of this document.
版本类型提供了语法版本号，以便与本文档的未来版本兼容。
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 may 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 }
11 Useful Attributes
11个有用的属性
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 2459 [PROFILE]. Some of the attributes defined in this section were originally defined in PKCS #9 [PKCS#9], others were not previously defined. The attributes are not listed in any particular order.
本节定义了可用于签名数据、信封数据、加密数据或认证数据的属性。属性的语法与X.501[X.501-88]和RFC 2459[PROFILE]兼容。本节中定义的一些属性最初是在PKCS#9[PKCS#9]中定义的，其他属性以前没有定义。属性没有按任何特定顺序列出。
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 value being signed in signed-data. The content-type attribute type is required if there are any authenticated attributes present.
content type属性类型指定在签名数据中签名的ContentInfo值的内容类型。如果存在任何经过身份验证的属性，则需要content type属性类型。
The content-type attribute must be a signed attribute or an authenticated attribute; it cannot be an unsigned attribute, an unauthenticated attribute, or an unprotectedAttribute.
内容类型属性必须是已签名属性或已验证属性；它不能是未签名的属性、未经身份验证的属性或未受保护的属性。
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
A content-type 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 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 is required if there are any attributes present. Within authenticated-data, the message-digest authenticated attribute type is required if there are any attributes present.
在签名数据中，如果存在任何属性，则需要消息摘要签名属性类型。在经过身份验证的数据中，如果存在任何属性，则需要消息摘要身份验证属性类型。
The message-digest attribute must be a signed attribute or an authenticated attribute; it cannot be an unsigned attribute or an unauthenticated 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 is defined as a SET OF Attributes. The SignedAttributes in a signerInfo must not include multiple instances of the message-digest attribute.
SignedAttribute语法定义为一组属性。signerInfo中的SignedAttribute不能包含消息摘要属性的多个实例。
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 may be a signed attribute; it cannot be an unsigned attribute, an authenticated attribute, or an unauthenticated 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 shall be interpreted as 19YY; and
若YY大于或等于50，则年份应解释为19YY；和
Where YY is less than 50, the year shall be interpreted as 20YY.
如果YY小于50，则年份应解释为20YY。
GeneralizedTime values shall 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 is defined as a SET OF Attributes. The SignedAttributes in a signerInfo must not include multiple instances of the signing-time attribute.
SignedAttribute语法定义为一组属性。signerInfo中的SignedAttribute不能包含signing time属性的多个实例。
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 cannot be a signed attribute, an authenticated attribute, or an unauthenticated 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 contain a message-digest attribute if it contains any other attributes, but need not contain a content-type attribute, as there is no content type for countersignatures.
1. 如果signedAttributes字段包含任何其他属性，则它必须包含消息摘要属性，但不需要包含内容类型属性，因为没有用于会签的内容类型。
2. 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.
2. 消息摘要处理的输入是属性关联的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 arbitrarily long series of countersignatures.
由于副署具有SignerInfo类型，因此它本身可以包含副署属性。因此，可以构造任意长系列的会签。
12 Supported Algorithms
12个支持的算法
This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included.
本节列出了必须实现的算法。还包括应实现的其他算法。
CMS implementations must include SHA-1. CMS implementations should include MD5.
CMS实施必须包括SHA-1。CMS实现应该包括MD5。
Digest algorithm identifiers are located in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field.
摘要算法标识符位于SignedData digestAlgorithms字段、SignerInfo digestAlgorithm字段、DigestedData digestAlgorithm字段和AuthenticatedData digestAlgorithm字段中。
Digest values are located in the DigestedData digest field, and digest values are located in the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms.
摘要值位于DigestedData摘要字段中，摘要值位于Message Digest authenticated属性中。此外，摘要值被输入到签名算法中。
The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is:
SHA-1摘要算法在FIPS Pub 180-1[SHA1]中定义。SHA-1的算法标识符为：
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The AlgorithmIdentifier parameters field is optional. If present, the parameters field must contain an ASN.1 NULL. Implementations should accept SHA-1 AlgorithmIdentifiers with absent parameters as well as NULL parameters. Implementations should generate SHA-1 AlgorithmIdentifiers with NULL parameters.
AlgorithmIdentifier参数字段是可选的。如果存在，参数字段必须包含ASN.1 NULL。实现应该接受没有参数和空参数的SHA-1算法标识符。实现应生成带有空参数的SHA-1算法标识符。
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm identifier for MD5 is:
MD5摘要算法在RFC 1321[MD5]中定义。MD5的算法标识符为：
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
The AlgorithmIdentifier parameters field must be present, and the parameters field must contain NULL. Implementations may accept the MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters.
AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含NULL。实现可能会接受MD5算法标识符，该标识符既有空参数，也有空参数。
CMS implementations must include DSA. CMS implementations may include RSA.
CMS实施必须包括DSA。CMS实现可能包括RSA。
Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
签名算法标识符位于SignerInfo signatureAlgorithm字段中。此外，签名算法标识符位于会签属性的SignerInfo signatureAlgorithm字段中。
Signature values are located in the SignerInfo signature field. Also, signature values are located in the SignerInfo signature field of countersignature attributes.
签名值位于SignerInfo签名字段中。此外，签名值位于会签属性的SignerInfo签名字段中。
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is:
DSA签名算法在FIPS Pub 186[DSS]中定义。DSA始终与SHA-1消息摘要算法一起使用。DSA的算法标识符为：
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
The AlgorithmIdentifier parameters field must not be present.
AlgorithmIdentifier参数字段不得存在。
The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 2347 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms. The algorithm identifier for RSA is:
RSA签名算法在RFC 2347[NEWPKCS#1]中定义。RFC 2347规定了RSA签名算法与SHA-1和MD5消息摘要算法的结合使用。RSA的算法标识符为：
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
CMS accommodates three general key management techniques: key agreement, key transport, and previously distributed symmetric key-encryption keys.
CMS包含三种通用密钥管理技术：密钥协议、密钥传输和以前分发的对称密钥加密密钥。
CMS implementations must include key agreement using X9.42 Ephemeral-Static Diffie-Hellman.
CMS实施必须包括使用X9.42瞬时静态Diffie-Hellman的密钥协议。
Any symmetric encryption algorithm that a CMS implementation includes as a content-encryption algorithm must also be included as a key-
CMS实现作为内容加密算法包含的任何对称加密算法也必须作为密钥包含-
encryption algorithm. CMS implementations must include key agreement of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption keys. CMS implementations should include key agreement of RC2 pairwise key-encryption keys and RC2 wrapping of RC2 content-encryption keys. The key wrap algorithm for Triple-DES and RC2 is described in section 12.3.3.
加密算法。CMS实施必须包括三重DES成对密钥加密密钥的密钥协议和三重DES内容加密密钥的三重DES包装。CMS实施应包括RC2成对密钥加密密钥的密钥协议和RC2内容加密密钥的RC2包装。第12.3.3节描述了三重DES和RC2的密钥包裹算法。
A CMS implementation may support mixed key-encryption and content-encryption algorithms. For example, a 128-bit RC2 content-encryption key may be wrapped with 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2 content-encryption key may be wrapped with 128-bit RC2 key-encryption key.
CMS实现可能支持混合密钥加密和内容加密算法。例如，128位RC2内容加密密钥可以用168位三重DES密钥加密密钥包装。类似地，40位RC2内容加密密钥可以用128位RC2密钥加密密钥包装。
For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2].
对于RC2密钥加密密钥的密钥协商，必须生成128位作为用于计算RC2有效密钥[RC2]的密钥扩展过程的输入。
Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
密钥协商算法标识符位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm和Authenticated Data RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中。
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
密钥换行算法标识符位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm和AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中的KeyWrapAlgorithm参数中。
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
包装的内容加密密钥位于EnvelopedData RecipientInfos KeyAgreement RecipientInfo RecipientEncryptedKeys encryptedKey字段中。包装消息身份验证密钥位于AuthenticatedData RecipientInfos KeyAgreement RecipientInfo RecipientEncryptedKeys encryptedKey字段中。
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows:
RFC 2631[DH-X9.42]中定义了瞬时静态Diffie-Hellman密钥协议。使用临时静态Diffie Hellman时，EnvelopedData RecipientInfos KeyAgreeRecipientInfo和Authenticated Data RecipientInfos KeyAgreeRecipientInfo字段的使用方式如下：
version must be 3.
版本必须为3。
originator must be the originatorKey alternative. The originatorKey algorithm fields must contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey field must contain the sender's ephemeral public key. The dh-public-number object identifier is:
发起人必须是发起人备选方案。原始工作算法字段必须包含缺少参数的dh public number对象标识符。OriginateWorkey公钥字段必须包含发件人的临时公钥。dh public number对象标识符为：
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be absent. When present, the ukm is used to ensure that a different key-encryption key is generated when the ephemeral private key might be used more than once.
ukm可能缺席。当存在时，ukm用于确保在临时私钥可能被多次使用时生成不同的密钥加密密钥。
keyEncryptionAlgorithm must be the id-alg-ESDH algorithm identifier. The algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorihtm, and this parameter must be present. The KeyWrapAlgorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the Ephemeral-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are discussed in section 12.3.3. The id-alg-ESDH algorithm identifier and parameter syntax is:
keyEncryptionAlgorithm必须是id alg ESDH算法标识符。id alg ESDH的算法标识符参数字段为KeyWrapAlgorihtm，该参数必须存在。KeyWrapAlgorithm表示对称加密算法，该算法用于使用临时静态Diffie-Hellman密钥协商算法生成的成对密钥加密密钥对内容加密密钥进行加密。第12.3.3节讨论了三重DES和RC2密钥封装算法。id alg ESDH算法标识符和参数语法为：
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier must contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static public key. RecipientEncryptedKey EncryptedKey must contain the content-encryption key encrypted with the Ephemeral-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgortihm.
recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态公钥。RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgortihm指定的算法使用短暂静态Diffie Hellman生成的成对密钥加密密钥加密的内容加密密钥。
CMS implementations should include key transport using RSA. RSA implementations must include key transport of Triple-DES content-encryption keys. RSA implementations should include key transport of RC2 content-encryption keys.
CMS实现应该包括使用RSA的密钥传输。RSA实现必须包括三重DES内容加密密钥的密钥传输。RSA实施应包括RC2内容加密密钥的密钥传输。
Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm fields.
密钥传输算法标识符位于EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm和Authenticated Data RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm字段中。
Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
密钥传输加密内容加密密钥位于EnvelopedData RecipientInfos密钥TransRecipientInfo encryptedKey中
field. Key transport encrypted message-authentication keys are located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo encryptedKey field.
领域密钥传输加密消息身份验证密钥位于AuthenticatedData RecipientInfos密钥TransRecipientInfo encryptedKey字段中。
The RSA key transport algorithm is the RSA encryption scheme defined in RFC 2313 [PKCS#1], block type is 02, where the message to be encrypted is the content-encryption key. The algorithm identifier for RSA is:
RSA密钥传输算法是RFC 2313[PKCS#1]中定义的RSA加密方案，块类型为02，其中要加密的消息是内容加密密钥。RSA的算法标识符为：
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field must be present, and the parameters field must contain NULL.
AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含NULL。
When using a Triple-DES content-encryption key, adjust the parity bits for each DES key comprising the Triple-DES key prior to RSA encryption.
使用三重DES内容加密密钥时，请在RSA加密之前调整包含三重DES密钥的每个DES密钥的奇偶校验位。
The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to provide confidentiality has a known vulnerability concerns. The vulnerability is primarily relevant to usage in interactive applications rather than to store-and-forward environments. Further information and proposed countermeasures are discussed in the Security Considerations section of this document.
使用RFC 2313[PKCS#1]中定义的RSA加密提供机密性存在已知的漏洞问题。该漏洞主要与交互应用程序中的使用有关，而不是与存储和转发环境有关。本文件的安全注意事项部分讨论了进一步的信息和建议的对策。
Note that the same encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES-PKCS1-v1_5.
请注意，RFC 2437[NEWPKCS#1]中也定义了相同的加密方案。在RFC 2437中，此方案称为RSAES-PKCS1-v1_5。
CMS implementations may include symmetric key-encryption key management. Such CMS implementations must include Triple-DES key-encryption keys wrapping Triple-DES content-encryption keys, and such CMS implementations should include RC2 key-encryption keys wrapping RC2 content-encryption keys. Only 128-bit RC2 keys may be used as key-encryption keys, and they must be used with the RC2ParameterVersion parameter set to 58. A CMS implementation may support mixed key-encryption and content-encryption algorithms. For example, a 40-bit RC2 content-encryption key may be wrapped with 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption key.
CMS实施可能包括对称密钥加密密钥管理。此类CMS实施必须包括包装三重DES内容加密密钥的三重DES密钥加密密钥，且此类CMS实施应包括包装RC2内容加密密钥的RC2密钥加密密钥。只有128位RC2密钥可以用作密钥加密密钥，并且必须在RC2ParameterVersion参数设置为58的情况下使用。CMS实现可能支持混合密钥加密和内容加密算法。例如，40位RC2内容加密密钥可以用168位三重DES密钥加密密钥或128位RC2密钥加密密钥包装。
Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm fields.
密钥包裹算法标识符位于EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm和Authenticated Data RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm字段中。
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field.
包装的内容加密密钥位于EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey字段中。包装消息身份验证密钥位于AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey字段中。
The output of a key agreement algorithm is a key-encryption key, and this key-encryption key is used to encrypt the content-encryption key. In conjunction with key agreement algorithms, CMS implementations must include encryption of content-encryption keys with the pairwise key-encryption key generated using a key agreement algorithm. To support key agreement, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
密钥协商算法的输出是密钥加密密钥，该密钥加密密钥用于加密内容加密密钥。结合密钥协商算法，CMS实施必须包括使用密钥协商算法生成的成对密钥加密密钥对内容加密密钥进行加密。为了支持密钥协商，密钥包裹算法标识符位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm和AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm字段的KeyWrapAlgorithm参数中。包装的内容加密密钥位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey字段中，包装的消息身份验证密钥位于AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey字段中。
Triple-DES key encryption has the algorithm identifier:
三重DES密钥加密具有算法标识符：
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field must be NULL.
AlgorithmIdentifier参数字段必须为空。
The key wrap algorithm used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key is specified in section 12.6.
第12.6节规定了用于使用三重DES密钥加密密钥加密三重DES内容加密密钥的密钥包裹算法。
Out-of-band distribution of the Triple-DES key-encryption key used to encrypt the Triple-DES content-encryption key is beyond of the scope of this document.
用于加密三重DES内容加密密钥的三重DES密钥加密密钥的带外分发超出了本文档的范围。
RC2 key encryption has the algorithm identifier:
RC2密钥加密具有算法标识符：
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
The AlgorithmIdentifier parameter field must be RC2wrapParameter:
AlgorithmIdentifier参数字段必须是RC2wrapParameter：
RC2wrapParameter ::= RC2ParameterVersion
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the RC2ParameterVersion. For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), because the one octet (A0) encoding represents a negative number.
大于32且小于256的RC2有效密钥位（密钥大小）在RC2参数版本中进行编码。对于有效密钥位40、64和128，RC2参数版本值分别为160、120和58。这些值不仅仅是RC2密钥长度。注意，值160必须编码为两个八位字节（00A0），因为一个八位字节（A0）编码表示负数。
Only 128-bit RC2 keys may be used as key-encryption keys, and they must be used with the RC2ParameterVersion parameter set to 58.
只有128位RC2密钥可以用作密钥加密密钥，并且必须在RC2ParameterVersion参数设置为58的情况下使用。
The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2 key-encryption key is specified in section 12.6.
第12.6节规定了用于使用RC2密钥加密密钥加密RC2内容加密密钥的密钥包裹算法。
Out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2 content-encryption key is beyond of the scope of this document.
用于加密RC2内容加密密钥的RC2密钥加密密钥的带外分发超出了本文档的范围。
CMS implementations must include Triple-DES in CBC mode. CMS implementations should include RC2 in CBC mode.
CMS实施必须包括CBC模式下的三重DES。CMS实施应包括CBC模式下的RC2。
Content encryption algorithms identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
内容加密算法标识符位于EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm和EncryptedData EncryptedContentInfo contentEncryptionAlgorithm字段中。
Content encryption algorithms are used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field.
内容加密算法用于加密位于EnvelopedData EncryptedContentInfo encryptedContent字段和EncryptedData EncryptedContentInfo encryptedContent字段中的内容。
The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The Triple-DES is composed from three sequential DES [DES] operations: encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different key for each DES operation. Two-Key Triple-DES uses one key for the two encrypt operations and different key for the decrypt operation. The same algorithm identifiers are used for Three-Key Triple-DES and Two-Key Triple-DES. The algorithm identifier for Triple-DES in Cipher Block Chaining (CBC) mode is:
ANSI X9.52[3DES]中描述了三重DES算法。三重DES由三个顺序DES[DES]操作组成：加密、解密和加密。三键三重DES对每个DES操作使用不同的键。双密钥三重DES使用一个密钥进行两次加密操作，使用不同的密钥进行解密操作。三键三重DES和两键三重DES使用相同的算法标识符。密码块链接（CBC）模式下三重DES的算法标识符为：
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
The AlgorithmIdentifier parameters field must be present, and the parameters field must contain a CBCParameter:
AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含CBC参数：
CBCParameter ::= IV
CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets
IV ::= OCTET STRING -- exactly 8 octets
The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm identifier for RC2 in CBC mode is:
RFC 2268[RC2]中描述了RC2算法。CBC模式下RC2的算法标识符为：
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
The AlgorithmIdentifier parameters field must be present, and the parameters field must contain a RC2CBCParameter:
AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含RC2CBCParameter：
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the rc2ParameterVersion. For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), since the one octet (A0) encoding represents a negative number.
大于32且小于256的RC2有效密钥位（密钥大小）在RC2参数版本中进行编码。对于有效密钥位40、64和128，RC2参数版本值分别为160、120和58。这些值不仅仅是RC2密钥长度。注意，值160必须编码为两个八位字节（00A0），因为一个八位字节（A0）编码表示负数。
CMS implementations that support authenticatedData must include HMAC with SHA-1.
支持authenticatedData的CMS实现必须包括HMAC和SHA-1。
MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field.
MAC算法标识符位于AuthenticatedData macAlgorithm字段中。
MAC values are located in the AuthenticatedData mac field.
MAC值位于AuthenticatedData MAC字段中。
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The algorithm identifier for HMAC with SHA-1 is:
RFC 2104[HMAC]中描述了带有SHA-1算法的HMAC。具有SHA-1的HMAC的算法标识符为：
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
The AlgorithmIdentifier parameters field must be absent.
AlgorithmIdentifier parameters字段必须不存在。
CMS implementations must include encryption of a Triple-DES content-encryption key with a Triple-DES key-encryption key using the algorithm specified in Sections 12.6.2 and 12.6.3. CMS implementations should include encryption of a RC2 content-encryption key with a RC2 key-encryption key using the algorithm specified in Sections 12.6.4 and 12.6.5. Triple-DES and RC2 content-encryption keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].
CMS实施必须包括使用第12.6.2节和第12.6.3节规定的算法，使用三重DES密钥加密密钥对三重DES内容加密密钥进行加密。CMS实施应包括使用第12.6.4节和第12.6.5节规定的算法，使用RC2密钥加密密钥对RC2内容加密密钥进行加密。三重DES和RC2内容加密密钥以密码块链接（CBC）模式[模式]进行加密。
Key Transport algorithms allow for the content-encryption key to be directly encrypted; however, key agreement and symmetric key-encryption key algorithms encrypt the content-encryption key with a second symmetric encryption algorithm. This section describes how the Triple-DES or RC2 content-encryption key is formatted and encrypted.
密钥传输算法允许直接加密内容加密密钥；但是，密钥协商和对称密钥加密密钥算法使用第二个对称加密算法加密内容加密密钥。本节介绍如何格式化和加密Triple DES或RC2内容加密密钥。
Key agreement algorithms generate a pairwise key-encryption key, and a key wrap algorithm is used to encrypt the content-encryption key with the pairwise key-encryption key. Similarly, a key wrap algorithm is used to encrypt the content-encryption key in a previously distributed key-encryption key.
密钥协商算法生成一个成对密钥加密密钥，密钥包裹算法用于使用成对密钥加密密钥对内容加密密钥进行加密。类似地，密钥包裹算法用于加密先前分发的密钥加密密钥中的内容加密密钥。
The key-encryption key is generated by the key agreement algorithm or distributed out of band. For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2].
密钥加密密钥由密钥协商算法生成或分发到带外。对于RC2密钥加密密钥的密钥协商，必须生成128位作为用于计算RC2有效密钥[RC2]的密钥扩展过程的输入。
The same algorithm identifier is used for both 2-key and 3-key Triple-DES. When the length of the content-encryption key to be wrapped is a 2-key Triple-DES key, a third key with the same value as the first key is created. Thus, all Triple-DES content-encryption keys are wrapped like 3-key Triple-DES keys.
相同的算法标识符用于2键和3键三重DES。当要包装的内容加密密钥的长度为2密钥三重DES密钥时，将创建与第一个密钥具有相同值的第三个密钥。因此，所有三重DES内容加密密钥都像三重DES密钥一样包装。
The CMS Checksum Algorithm is used to provide a content-encryption key integrity check value. The algorithm is:
CMS校验和算法用于提供内容加密密钥完整性校验值。算法是：
1. Compute a 20 octet SHA-1 [SHA1] message digest on the content-encryption key. 2. Use the most significant (first) eight octets of the message digest value as the checksum value.
1. 在内容加密密钥上计算20个八位组的SHA-1[SHA1]消息摘要。2.使用消息摘要值的最高有效（前）八位字节作为校验和值。
The Triple-DES key wrap algorithm encrypts a Triple-DES content-encryption key with a Triple-DES key-encryption key. The Triple-DES key wrap algorithm is:
三重DES密钥包裹算法使用三重DES密钥加密密钥加密三重DES内容加密密钥。三重DES密钥包裹算法是：
1. Set odd parity for each of the DES key octets comprising the content-encryption key, call the result CEK. 2. Compute an 8 octet key checksum value on CEK as described above in Section 12.6.1, call the result ICV. 3. Let CEKICV = CEK || ICV. 4. Generate 8 octets at random, call the result IV. 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use the random value generated in the previous step as the initialization vector (IV). Call the ciphertext TEMP1. 6. Let TEMP2 = IV || TEMP1. 7. Reverse the order of the octets in TEMP2. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP3. 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. The ciphertext is 40 octets long.
1. 为包含内容加密密钥的每个DES密钥八位组设置奇数奇偶校验，调用结果CEK。2.如上文第12.6.1节所述，计算CEK上的8个八位键校验和值，调用结果ICV。3.设CEKICV=CEK | | ICV。4.随机生成8个八位组，调用结果IV.5。使用密钥加密密钥在CBC模式下加密CEKICV。使用上一步中生成的随机值作为初始化向量（IV）。调用密文TEMP1。6.设TEMP2=IV | | TEMP1。7.颠倒TEMP2中八位字节的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP3。8.使用密钥加密密钥在CBC模式下加密TEMP3。使用0x4adda22c79e82105的初始化向量（IV）。密文有40个八位字节长。
Note: When the same content-encryption key is wrapped in different key-encryption keys, a fresh initialization vector (IV) must be generated for each invocation of the key wrap algorithm.
注意：当相同的内容加密密钥包装在不同的密钥加密密钥中时，必须为每次调用密钥包装算法生成一个新的初始化向量（IV）。
The Triple-DES key unwrap algorithm decrypts a Triple-DES content-encryption key using a Triple-DES key-encryption key. The Triple-DES key unwrap algorithm is:
三重DES密钥展开算法使用三重DES密钥加密密钥对三重DES内容加密密钥进行解密。三重DES密钥展开算法为：
1. If the wrapped content-encryption key is not 40 octets, then error. 2. Decrypt the wrapped content-encryption key in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
1. 如果包装的内容加密密钥不是40个八位字节，则返回错误。2.使用密钥加密密钥在CBC模式下解密包装的内容加密密钥。使用0x4adda22c79e82105的初始化向量（IV）。调用输出TEMP3。
3. Reverse the order of the octets in TEMP3. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP2. 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is the least significant (last) 32 octets. 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the IV value from the previous step as the initialization vector. Call the ciphertext CEKICV. 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant (first) 24 octets, and ICV is the least significant (last) 8 octets. 7. Compute an 8 octet key checksum value on CEK as described above in Section 12.6.1. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error. 8. Check for odd parity each of the DES key octets comprising CEK. If parity is incorrect, then there is an error. 9. Use CEK as the content-encryption key.
3. 在TEMP3中颠倒八位组的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP2。4.将TEMP2分解为IV和TEMP1。IV是最重要的（前）8个八位字节，TEMP1是最不重要的（后）32个八位字节。5.使用密钥加密密钥在CBC模式下解密TEMP1。使用上一步中的IV值作为初始化向量。调用密文CEKICV。6.将CEKICV分解为CEK和ICV。CEK是最重要的（前）24个八位字节，ICV是最不重要的（后）8个八位字节。7.如上文第12.6.1节所述，在CEK上计算8个八位键的校验和值。如果计算的密钥校验和值与解密的密钥校验和值ICV不匹配，则出现错误。8.检查组成CEK的每个DES键八位字节是否奇偶校验。如果奇偶校验不正确，则存在错误。9使用CEK作为内容加密密钥。
The RC2 key wrap algorithm encrypts a RC2 content-encryption key with a RC2 key-encryption key. The RC2 key wrap algorithm is:
RC2密钥包裹算法使用RC2密钥加密密钥对RC2内容加密密钥进行加密。RC2密钥换行算法是：
1. Let the content-encryption key be called CEK, and let the length of the content-encryption key in octets be called LENGTH. LENGTH is a single octet. 2. Let LCEK = LENGTH || CEK. 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple of 8, the PAD has a length of zero. If the length of LCEK is not a multiple of 8, then PAD contains the fewest number of random octets to make the length of LCEKPAD a multiple of 8. 4. Compute an 8 octet key checksum value on LCEKPAD as described above in Section 12.6.1, call the result ICV. 5. Let LCEKPADICV = LCEKPAD || ICV. 6. Generate 8 octets at random, call the result IV. 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. Use the random value generated in the previous step as the initialization vector (IV). Call the ciphertext TEMP1. 8. Let TEMP2 = IV || TEMP1. 9. Reverse the order of the octets in TEMP2. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP3. 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105.
1. 将内容加密密钥称为CEK，并将内容加密密钥的长度（以八位字节为单位）称为length。长度是一个八位组。2.设LCEK=长度| | CEK。3.让LCEKPAD=LCEK | | PAD。如果LCEK的长度是8的倍数，则焊盘的长度为零。如果LCEK的长度不是8的倍数，则PAD包含的随机八位字节数最少，以使LCEKPAD的长度为8的倍数。4.如上文第12.6.1节所述，在LCEKPAD上计算8个八位键的校验和值，调用结果ICV。5.设LCEKPADICV=LCEKPAD | | ICV。6.随机生成8个八位组，调用结果IV.7。使用密钥加密密钥在CBC模式下加密LCEKPADICV。使用上一步中生成的随机值作为初始化向量（IV）。调用密文TEMP1。8.设TEMP2=IV | | TEMP1。9颠倒TEMP2中八位字节的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP3。10使用密钥加密密钥在CBC模式下加密TEMP3。使用0x4adda22c79e82105的初始化向量（IV）。
Note: When the same content-encryption key is wrapped in different key-encryption keys, a fresh initialization vector (IV) must be generated for each invocation of the key wrap algorithm.
注意：当相同的内容加密密钥包装在不同的密钥加密密钥中时，必须为每次调用密钥包装算法生成一个新的初始化向量（IV）。
The RC2 key unwrap algorithm decrypts a RC2 content-encryption key using a RC2 key-encryption key. The RC2 key unwrap algorithm is:
RC2密钥展开算法使用RC2密钥加密密钥对RC2内容加密密钥进行解密。RC2密钥展开算法为：
1. If the wrapped content-encryption key is not a multiple of 8 octets, then error. 2. Decrypt the wrapped content-encryption key in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3. 3. Reverse the order of the octets in TEMP3. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP2. 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is the remaining octets.
1. 如果包装的内容加密密钥不是8个八位字节的倍数，则返回错误。2.使用密钥加密密钥在CBC模式下解密包装的内容加密密钥。使用0x4adda22c79e82105的初始化向量（IV）。调用输出TEMP3。3.在TEMP3中颠倒八位组的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP2。4.将TEMP2分解为IV和TEMP1。IV是最重要的（前）8个八位字节，TEMP1是剩余的八位字节。
5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the IV value from the previous step as the initialization vector. Call the plaintext LCEKPADICV. 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the least significant (last) octet 8 octets. LCEKPAD is the remaining octets. 7. Compute an 8 octet key checksum value on LCEKPAD as described above in Section 12.6.1. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error. 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the most significant (first) octet. CEK is the following LENGTH octets. PAD is the remaining octets, if any. 9. If the length of PAD is more than 7 octets, then error. 10. Use CEK as the content-encryption key.
5. 使用密钥加密密钥在CBC模式下解密TEMP1。使用上一步中的IV值作为初始化向量。调用明文LCEKPADICV。6.将LCEKPADICV分解为LCEKPAD和ICV。ICV是最不显著（最后）的八位字节8个八位字节。LCEKPAD是剩余的八位字节。7.如上文第12.6.1节所述，在LCEKPAD上计算8个八位键的校验和值。如果计算的密钥校验和值与解密的密钥校验和值ICV不匹配，则出现错误。8.将LCEKPAD分解为长度、CEK和PAD。长度是最重要的（第一个）八位组。CEK是以下长度的八位字节。PAD是剩余的八位字节（如果有）。9如果PAD的长度超过7个八位字节，则为错误。10使用CEK作为内容加密密钥。
Appendix A: ASN.1 Module
附录A:ASN.1模块
CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
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
进口
-- Directory Information Framework (X.501) Name FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) informationFramework(1) 3 }
--目录信息框架（X.501）来自InformationFramework的名称{joint-iso-itu-t ds（5）模块（1）InformationFramework（1）3}
-- Directory Authentication Framework (X.509) AlgorithmIdentifier, AttributeCertificate, Certificate, CertificateList, CertificateSerialNumber FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 } ;
--目录身份验证框架（X.509）算法标识符、属性证书、证书、证书列表、来自身份验证框架的证书序列号{joint-iso-itu-t ds（5）模块（1）身份验证框架（7）3}；
-- Cryptographic Message Syntax
--加密消息语法
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT 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
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 OF RecipientInfo
RecipientInfos ::= SET 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 }
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo }
EncryptedKey ::= OCTET STRING
EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING
SubjectKeyIdentifier ::= OCTET STRING
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
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,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthenticatedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthenticatedAttributes [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
CertificateRevocationLists ::= SET OF CertificateList
CertificateRevocationLists ::= SET OF CertificateList
CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
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 }
-- 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
-- Algorithm Identifiers
--算法标识符
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
-- Algorithm Parameters
--算法参数
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm ::= AlgorithmIdentifier
RC2wrapParameter ::= RC2ParameterVersion
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
RC2ParameterVersion ::= INTEGER
CBCParameter ::= IV
CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets
IV ::= OCTET STRING -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
-- Content Type Object Identifiers
--内容类型对象标识符
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 6 }
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 6 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
-- 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中过时的扩展证书语法
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
Signature ::= BIT STRING
Signature ::= BIT STRING
END -- of CryptographicMessageSyntax
END--加密消息语法的结束
References
工具书类
3DES American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
3DES美国国家标准协会。ANSI X9.52-1998，三重数据加密算法操作模式。1998
DES American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983.
美国国家标准协会。ANSI X3.106，“美国信息系统国家标准-数据链路加密”。1983
DH-X9.42 Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
DH-X9.42 Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
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., Editor, "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
ESS Hoffman，P.，编辑，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
HMAC Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
HMAC Krawczyk，H.，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
MD5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
MD5 Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
MODES National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
美国国家标准与技术研究所。FIPS Pub 81:DES操作模式。1980年12月2日。
MSG Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
MSG Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2347, October 1998.
NEWPKCS#1 Kaliski，B.，“PKCS#1:RSA加密，2.0版”，RFC 2347，1998年10月。
PROFILE Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999.
简介Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施：证书和CRL简介”，RFC 2459，1999年1月。
PKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.", RFC 2313, March 1998.
PKCS#1 Kaliski，B.，“PKCS#1:RSA加密，1.5版”，RFC 2313，1998年3月。
PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.
PKCS#6 RSA实验室。PKCS#6：扩展证书语法标准，版本1.5。1993年11月。
PKCS#7 Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version 1.5.", RFC 2315, March 1998.
PKCS#7 Kaliski，B.，“PKCS#7：加密消息语法，版本1.5.”，RFC 2315，1998年3月。
PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993.
PKCS#9 RSA实验室。PKCS#9：选定属性类型，版本1.1。1993年11月。
RANDOM Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
RANDOM Eastlake，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
RC2 Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, March 1998.
RC2 Rivest，R.，“RC2（R）加密算法的描述”，RFC 2268，1998年3月。
SHA1 National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
SHA1国家标准与技术研究所。FIPS Pub 180-1：安全哈希标准。1995年4月17日。
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
Security Considerations
安全考虑
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 messages 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.
实现必须保护密钥管理私钥和消息身份验证密钥。密钥管理私钥的泄露允许伪装经过身份验证的数据。类似地，消息认证密钥的泄露可能导致认证内容的不可检测的修改。
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, a message content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 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 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位Triple-DES加密，并且Triple-DES内容加密密钥使用40位RC2密钥包装，则最多提供40位保护。确定40位RC2密钥值的简单搜索可以恢复三重DES密钥，然后可以使用三重DES密钥解密内容。因此，实现者必须确保密钥加密算法与内容加密算法一样强大。
Section 12.6 specifies key wrap algorithms used to encrypt a Triple-DES [3DES] content-encryption key with a Triple-DES key-encryption key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-encryption key. The key wrap algorithms make use of CBC mode [MODES]. These key wrap algorithms have been reviewed for use with Triple and RC2. They have not been reviewed for use with other cryptographic modes or other encryption algorithms. Therefore, if a CMS implementation wishes to support ciphers in addition to Triple-DES or RC2, then additional key wrap algorithms need to be defined to support the additional ciphers.
第12.6节规定了用于使用三重DES密钥加密密钥加密三重DES[3DES]内容加密密钥或使用RC2密钥加密密钥加密RC2[RC2]内容加密密钥的密钥封装算法。密钥包裹算法使用CBC模式[模式]。这些密钥封装算法已被审查用于Triple和RC2。尚未审查它们是否与其他加密模式或其他加密算法一起使用。因此，如果CMS实现希望支持除三重DES或RC2之外的密码，则需要定义额外的密钥包裹算法以支持额外的密码。
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 reduce. Therefore, cryptographic algorithm implementations should be modular allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory to implement algorithms to change over time.
实现者应该意识到加密算法会随着时间的推移变得越来越弱。随着新密码分析技术的发展和计算性能的提高，破坏特定密码算法的工作因素将减少。因此，密码算法的实现应该是模块化的，这样就可以很容易地插入新的算法。也就是说，实现者应该准备好一组强制算法，以实现随时间变化的算法。
The countersignature unauthenticated 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.
这种结构允许实现效率优势；但是，此结构也允许对不适当的签名值进行会签。因此，执行会签的实现应该在会签之前验证原始签名值（此验证需要处理原始内容），或者在确保只会签适当的签名值的上下文中执行会签。
Users of CMS, particularly those employing CMS to support interactive applications, should be aware that PKCS #1 Version 1.5 as specified in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext attacks when applied for encryption purposes. Exploitation of this identified vulnerability, revealing the result of a particular RSA decryption, requires access to an oracle which will respond to a large number of ciphertexts (based on currently available results, hundreds of thousands or more), which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations. As a result, the attack appears significantly less feasible to perpetrate for store-and-forward S/MIME environments than for directly interactive protocols. Where CMS constructs are applied as an intermediate encryption layer within an interactive request-response communications environment, exploitation could be more feasible.
CMS的用户，特别是那些使用CMS支持交互式应用程序的用户，应该意识到RFC 2313[PKCS#1]中规定的PKCS#1版本1.5在用于加密目的时容易受到自适应选择密文攻击。利用此已识别的漏洞（显示特定RSA解密的结果）需要访问oracle，oracle将响应大量密文（基于当前可用的结果，数十万或更多），根据先前接收到的回复自适应构造，提供尝试解密操作的成功或失败信息。因此，与直接交互协议相比，存储转发S/MIME环境中的攻击似乎不太可行。当CMS构造作为交互请求-响应通信环境中的中间加密层应用时，利用CMS构造可能更可行。
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 Version 2.0 preserves support for the encryption padding format defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 Version 2.0 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption is used to provide confidentiality. Designers of protocols and systems employing CMS for interactive environments should either consider usage of OAEP, or should ensure that information which could reveal the success or failure of attempted PKCS #1 Version 1.5 decryption operations is not provided. Support for OAEP will likely be added to a future version of the CMS specification.
PKCS#1的更新版本已经发布，PKCS#1版本2.0[NEWPKCS#1]。本新文件将取代RFC 2313。PKCS#1 2.0版保留了对PKCS#1 1.5版[PKCS#1]中定义的加密填充格式的支持，并定义了一个新的替代方案。为了解决自适应选择密文漏洞，PKCS#1 2.0版规定并建议在使用RSA加密提供机密性时使用最佳非对称加密填充（OAEP）。用于交互环境的采用CMS的协议和系统的设计者应该考虑OAEP的使用，或者应该确保不提供试图进行PKC第1版1.5解密操作的成功或失败的信息。对OAEP的支持可能会添加到CMS规范的未来版本中。
Acknowledgments
致谢
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, 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、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的努力和支持。
Author's Address
作者地址
Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA
拉塞尔·霍斯利·斯皮罗斯美国弗吉尼亚州赫恩登市埃尔登街381号1120室，邮编20170
EMail: housley@spyrus.com
EMail: housley@spyrus.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。