Network Working Group R. Housley
Request for Comments: 3370 RSA Laboratories
Obsoletes: 2630, 3211 August 2002
Category: Standards Track
Network Working Group R. Housley
Request for Comments: 3370 RSA Laboratories
Obsoletes: 2630, 3211 August 2002
Category: Standards Track
Cryptographic Message Syntax (CMS) Algorithms
加密消息语法（CMS）算法
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS). The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
本文档描述了使用加密消息语法（CMS）的几种加密算法的约定。CMS用于对任意消息内容进行数字签名、摘要、身份验证或加密。
Table of Contents
目录
1 Introduction ............................................... 2
1.1 Changes Since RFC 2630 ..................................... 2
1.2 Terminology ................................................ 2
2 Message Digest Algorithms .................................. 3
2.1 SHA-1 ...................................................... 3
2.2 MD5 ........................................................ 3
3 Signature Algorithms ....................................... 4
3.1 DSA ........................................................ 4
3.2 RSA ........................................................ 5
4 Key Management Algorithms .................................. 6
4.1 Key Agreement Algorithms ................................... 6
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ...................... 7
4.1.2 X9.42 Static-Static Diffie-Hellman ......................... 8
4.2 Key Transport Algorithms ................................... 9
4.2.1 RSA (PKCS #1 v1.5) ......................................... 10
4.3 Symmetric Key-Encryption Key Algorithms .................... 10
4.3.1 Triple-DES Key Wrap ........................................ 11
4.3.2 RC2 Key Wrap ............................................... 12
4.4 Key Derivation Algorithms .................................. 12
1 Introduction ............................................... 2
1.1 Changes Since RFC 2630 ..................................... 2
1.2 Terminology ................................................ 2
2 Message Digest Algorithms .................................. 3
2.1 SHA-1 ...................................................... 3
2.2 MD5 ........................................................ 3
3 Signature Algorithms ....................................... 4
3.1 DSA ........................................................ 4
3.2 RSA ........................................................ 5
4 Key Management Algorithms .................................. 6
4.1 Key Agreement Algorithms ................................... 6
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ...................... 7
4.1.2 X9.42 Static-Static Diffie-Hellman ......................... 8
4.2 Key Transport Algorithms ................................... 9
4.2.1 RSA (PKCS #1 v1.5) ......................................... 10
4.3 Symmetric Key-Encryption Key Algorithms .................... 10
4.3.1 Triple-DES Key Wrap ........................................ 11
4.3.2 RC2 Key Wrap ............................................... 12
4.4 Key Derivation Algorithms .................................. 12
4.4.1 PBKDF2 ..................................................... 13
5 Content Encryption Algorithms .............................. 13
5.1 Triple-DES CBC ............................................. 14
5.2 RC2 CBC .................................................... 14
6 Message Authentication Code (MAC) Algorithms ............... 15
6.1 HMAC with SHA-1 ............................................ 15
7 ASN.1 Module ............................................... 16
8 References ................................................. 18
9 Security Considerations .................................... 20
10 Acknowledgments ............................................ 22
11 Author's Address ........................................... 23
12 Full Copyright Statement ................................... 24
4.4.1 PBKDF2 ..................................................... 13
5 Content Encryption Algorithms .............................. 13
5.1 Triple-DES CBC ............................................. 14
5.2 RC2 CBC .................................................... 14
6 Message Authentication Code (MAC) Algorithms ............... 15
6.1 HMAC with SHA-1 ............................................ 15
7 ASN.1 Module ............................................... 16
8 References ................................................. 18
9 Security Considerations .................................... 20
10 Acknowledgments ............................................ 22
11 Author's Address ........................................... 23
12 Full Copyright Statement ................................... 24
1 Introduction
1导言
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. This companion specification describes the use of common cryptographic algorithms with the CMS. Implementations of the CMS may support these algorithms; implementations of the CMS may also support other algorithms as well. However, if an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document.
加密消息语法（CMS）[CMS]用于对任意消息内容进行数字签名、摘要、身份验证或加密。本配套规范描述了CMS中常用加密算法的使用。CMS的实现可能支持这些算法；CMS的实现也可能支持其他算法。但是，如果一个实现选择支持本文档中讨论的算法之一，那么该实现必须按照本文档中的描述执行。
The CMS values are generated using ASN.1 [X.208-88], using BER-encoding [X.209-88]. Algorithm identifiers (which include ASN.1 object identifiers) identify cryptographic algorithms, and some algorithms require additional parameters. When needed, parameters are specified with an ASN.1 structure. The algorithm identifier for each algorithm is specified, and when needed, the parameter structure is specified. The fields in the CMS employed by each algorithm are identified.
CMS值是使用ASN.1[X.208-88]和BER编码[X.209-88]生成的。算法标识符（包括ASN.1对象标识符）标识加密算法，有些算法需要额外的参数。需要时，使用ASN.1结构指定参数。指定每个算法的算法标识符，并在需要时指定参数结构。识别每个算法使用的CMS中的字段。
This document obsoletes section 12 of RFC 2630 [OLDCMS]. RFC 3369 [CMS] obsoletes the rest of RFC 2630. Separation of the protocol and algorithm specifications allows each one to be updated without impacting the other. However, the conventions for using additional algorithms with the CMS are likely to be specified in separate documents.
本文件废除了RFC 2630[OLDCMS]第12节。RFC 3369[CMS]淘汰了RFC 2630的其余部分。协议和算法规范的分离允许在不影响其他规范的情况下更新每一个规范。然而，在CMS中使用附加算法的约定可能会在单独的文档中指定。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described in [STDWORDS].
在本文件中，关键词必须、不得、必需、应该、不应该、建议，并可能按照[STDWORDS]中的描述进行解释。
2 Message Digest Algorithms
2消息摘要算法
This section specifies the conventions employed by CMS implementations that support SHA-1 or MD5.
本节规定了支持SHA-1或MD5的CMS实现所采用的约定。
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 the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms.
摘要值位于DigestedData摘要字段和Message Digest authenticated属性中。此外，摘要值被输入到签名算法中。
The SHA-1 message 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 }
There are two possible encodings for the SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field which contains a NULL.
SHA-1算法标识符参数字段有两种可能的编码。这两个备选方案产生于这样一个事实：当1988年AlgorithmIdentifier语法被翻译成1997年语法时，与AlgorithmIdentifier参数相关的可选语法丢失了。后来通过缺陷报告恢复了可选的，但那时许多人认为算法参数是强制性的。由于这种历史，一些实现将参数编码为空元素，而另一些实现则完全忽略它们。正确的编码是省略参数字段；但是，实现还必须处理包含空值的SHA-1 AlgorithmIdentifier parameters字段。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifier参数字段是可选的。如果存在，参数字段必须包含空值。实现必须接受没有参数的SHA-1算法标识符。实现必须接受带有空参数的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算法标识符，该标识符既有空参数，也有空参数。
3 Signature Algorithms
3签名算法
This section specifies the conventions employed by CMS implementations that support DSA or RSA (PKCS #1 v1.5).
本节规定了支持DSA或RSA（PKCS#1 v1.5）的CMS实现所采用的约定。
Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
签名算法标识符位于SignedData的SignerInfo signatureAlgorithm字段中。此外，签名算法标识符位于会签属性的SignerInfo signatureAlgorithm字段中。
Signature values are located in the SignerInfo signature field of SignedData. Also, signature values are located in the SignerInfo signature field of countersignature attributes.
签名值位于SignedData的SignerInfo签名字段中。此外，签名值位于会签属性的SignerInfo签名字段中。
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA MUST be used with the SHA-1 message digest algorithm.
DSA签名算法在FIPS Pub 186[DSS]中定义。DSA必须与SHA-1消息摘要算法一起使用。
The algorithm identifier for DSA subject public keys in certificates is:
证书中DSA主题公钥的算法标识符为：
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 1 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 1 }
DSA signature validation requires three parameters, commonly called p, q, and g. When the id-dsa algorithm identifier is used, the AlgorithmIdentifier parameters field is optional. If present, the AlgorithmIdentifier parameters field MUST contain the three DSA parameter values encoded using the Dss-Parms type. If absent, the subject DSA public key uses the same DSA parameters as the certificate issuer.
DSA签名验证需要三个参数，通常称为p、q和g。使用id dsa算法标识符时，AlgorithmIdentifier parameters字段是可选的。如果存在，AlgorithmIdentifier parameters字段必须包含使用Dss Parms类型编码的三个DSA参数值。如果不存在，主体DSA公钥将使用与证书颁发者相同的DSA参数。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
When the id-dsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key.
使用id dsa算法标识符时，dsa公钥（通常称为Y）必须编码为整数。此编码的输出包含在证书使用者公钥中。
Dss-Pub-Key ::= INTEGER -- Y
Dss-Pub-Key ::= INTEGER -- Y
The algorithm identifier for DSA with SHA-1 signature values is:
具有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 }
When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
使用id-dsa-with-sha1算法标识符时，必须缺少AlgorithmIdentifier参数字段。
When signing, the DSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the Dss-Sig-Value type:
签名时，DSA算法生成两个值，通常称为r和s。要将这两个值作为一个签名传输，必须使用Dss Sig Value类型对其进行编码：
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
The RSA (PKCS #1 v1.5) signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 2437 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms.
RSA（PKCS#1 v1.5）签名算法在RFC 2437[NEWPKCS#1]中定义。RFC 2437规定了RSA签名算法与SHA-1和MD5消息摘要算法的结合使用。
The algorithm identifier for RSA subject public keys in certificates is:
证书中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 }
When the rsaEncryption algorithm identifier is used, the AlgorithmIdentifier parameters field MUST contain NULL.
使用RSA加密算法标识符时，AlgorithmIdentifier参数字段必须包含NULL。
When the rsaEncryption algorithm identifier is used, the RSA public key, which is composed of a modulus and a public exponent, MUST be encoded using the RSAPublicKey type. The output of this encoding is carried in the certificate subject public key.
当使用RSA加密算法标识符时，RSA公钥（由模数和公共指数组成）必须使用RSA公钥类型进行编码。此编码的输出包含在证书使用者公钥中。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST also implement the SHA-1 message digest algorithm. Such implementations SHOULD also support the MD5 message digest algorithm.
包括RSA（PKCS#1 v1.5）签名算法的CMS实现还必须实现SHA-1消息摘要算法。此类实现还应支持MD5消息摘要算法。
The rsaEncryption algorithm identifier is used to identify RSA (PKCS #1 v1.5) signature values regardless of the message digest algorithm employed. CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST support the rsaEncryption signature value algorithm identifier, and CMS implementations MAY support RSA (PKCS #1 v1.5) signature value algorithm identifiers that specify both the RSA (PKCS #1 v1.5) signature algorithm and the message digest algorithm.
RSA加密算法标识符用于识别RSA（PKCS#1 v1.5）签名值，无论采用何种消息摘要算法。包含RSA（PKCS#1 v1.5）签名算法的CMS实现必须支持RSA加密签名值算法标识符，CMS实现可能支持指定RSA（PKCS#1 v1.5）签名算法和消息摘要算法的RSA（PKCS#1 v1.5）签名值算法标识符。
The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature values is:
具有SHA-1签名值的RSA（PKCS#1 v1.5）的算法标识符为：
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is:
具有MD5签名值的RSA（PKCS#1 v1.5）的算法标识符为：
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
When the rsaEncryption, sha1WithRSAEncryption, or md5WithRSAEncryption signature value algorithm identifiers are used, the AlgorithmIdentifier parameters field MUST be NULL.
当使用RSANYPTION、SHA1 WITHRSANYPTION或MD5WITHRSANYPTION签名值算法标识符时，AlgorithmIdentifier参数字段必须为空。
When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.
签名时，RSA算法生成一个值，该值直接用作签名值。
4 Key Management Algorithms
4种密钥管理算法
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords.
CMS包含以下通用密钥管理技术：密钥协议、密钥传输、以前分发的对称密钥加密密钥和密码。
This section specifies the conventions employed by CMS implementations that support key agreement using X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).
本节规定了CMS实现所采用的约定，这些约定支持使用X9.42瞬时静态Diffie-Hellman（X9.42 E-S D-H）和X9.42静态Diffie-Hellman（X9.42 S-S D-H）进行密钥协商。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. Therefore, when key agreement is supported, a key-encryption algorithm MUST be provided for each content-encryption algorithm. The key wrap algorithms for Triple-DES and RC2 are described in RFC 3217 [WRAP].
当使用密钥协商算法时，还需要密钥加密算法。因此，当支持密钥协议时，必须为每个内容加密算法提供密钥加密算法。RFC 3217[wrap]中描述了三重DES和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 field is used as follows:
RFC 2631[DH-X9.42]中定义了瞬时静态Diffie-Hellman密钥协议。使用临时静态Diffie Hellman时，EnvelopedData RecipientInfos KeyAgreeRecipientInfo字段的使用方式如下：
version MUST be 3.
版本必须为3。
originator MUST be the originatorKey alternative. The originatorKey algorithm field 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:
发起人必须是发起人备选方案。OriginateWorkey算法字段必须包含缺少参数的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 present or absent. CMS implementations MUST support ukm being absent, and CMS implementations SHOULD support ukm being present. 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可能出席或缺席。CMS实现必须支持ukm不存在，CMS实现应该支持ukm存在。当存在时，ukm用于确保在临时私钥可能被多次使用时生成不同的密钥加密密钥。
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm identifier. The algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorithm, 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 X9.42 Ephemeral-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-ESDH algorithm identifier and parameter syntax is:
keyEncryptionAlgorithm必须是id alg ESDH算法标识符。id alg ESDH的算法标识符参数字段为KeyWrapAlgorithm，该参数必须存在。KeyWrapAlgorithm表示对称加密算法，用于使用使用X9.42瞬时静态Diffie-Hellman密钥协商算法生成的成对密钥加密密钥加密内容加密密钥。RFC 3217[wrap]中描述了三重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 X9.42 Ephemeral-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态公钥。RecipientEncryptedKey EncryptedKey必须包含使用X9.42临时静态Diffie Hellman生成的成对密钥加密密钥加密的内容加密密钥，加密密钥使用KeyWrapAlgorithm指定的算法。
Static-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Static-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows:
静态Diffie-Hellman密钥协议在RFC 2631[DH-X9.42]中定义。使用静态Diffie-Hellman时，EnvelopedData RecipientInfos KeyAgreeRecipientInfo和Authenticated Data RecipientInfos KeyAgreeRecipientInfo字段的使用方式如下：
version MUST be 3.
版本必须为3。
originator MUST be either the issuerAndSerialNumber or subjectKeyIdentifier alternative. In both cases, the originator's certificate contains the sender's static public key. RFC 3279 [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and values that are included in the originator's certificate. The originator's certificate subject public key information field MUST contain the dh-public-number object identifier:
发起者必须是issuerAndSerialNumber或subjectKeyIdentifier替代者。在这两种情况下，发起者的证书都包含发送者的静态公钥。RFC 3279[CERTALGS]指定发起人证书中包含的算法标识符参数语法和值。发起人的证书主题公钥信息字段必须包含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 MUST be present. The ukm ensures that a different key-encryption key is generated for each message between the same sender and recipient.
ukm必须在场。ukm确保为同一发件人和收件人之间的每条邮件生成不同的密钥加密密钥。
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm identifier. The algorithm identifier parameter field for id-alg-SSDH 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 X9.42 Static-Static Diffie-Hellman key agreement algorithm. Triple-DES and RC2 key wrap algorithms are described in RFC 3217 [WRAP]. The id-alg-SSDH algorithm identifier and parameter syntax is:
keyEncryptionAlgorithm必须是id alg SSDH算法标识符。id alg SSDH的算法标识符参数字段为KeyWrapAlgorihtm，该参数必须存在。KeyWrapAlgorithm表示对称加密算法，用于使用使用X9.42静态Diffie-Hellman密钥协商算法生成的成对密钥加密密钥加密内容加密密钥。RFC 3217[wrap]中描述了三重DES和RC2密钥包裹算法。id alg SSDH算法标识符和参数语法为：
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 }
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 }
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 X9.42 Static-Static Diffie-Hellman generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgortihm.
recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态公钥。RecipientEncryptedKey EncryptedKey必须包含使用X9.42静态Diffie-Hellman生成的成对密钥加密密钥加密的内容加密密钥，加密密钥使用KeyWrapAlgortihm指定的算法。
This section specifies the conventions employed by CMS implementations that support key transport using RSA (PKCS #1 v1.5).
本节规定了支持使用RSA（PKCS#1 v1.5）进行密钥传输的CMS实现所采用的约定。
Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
密钥传输算法标识符位于EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm字段中。
Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field.
密钥传输加密内容加密密钥位于EnvelopedData 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 (PKCS #1 v1.5) is:
RSA密钥传输算法是RFC 2313[PKCS#1]中定义的RSA加密方案，块类型为02，其中要加密的消息是内容加密密钥。RSA（PKCS#1 v1.5）的算法标识符为：
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, CMS implementations MUST adjust the parity bits for each DES key comprising the Triple-DES key prior to RSA encryption.
当使用三重DES内容加密密钥时，CMS实现必须在RSA加密之前调整包含三重DES密钥的每个DES密钥的奇偶校验位。
The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 [PKCS#1], to provide confidentiality has a known vulnerability. 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 and RFC 3218 [MMA].
使用RFC 2313[PKCS#1]中定义的RSA（PKCS#1 v1.5）加密提供机密性存在已知漏洞。该漏洞主要与交互应用程序中的使用有关，而不是与存储和转发环境有关。本文件和RFC 3218[MMA]的安全注意事项部分讨论了进一步的信息和建议的对策。
Note that the same RSA encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called RSAES-PKCS1-v1_5.
请注意，RFC 2437[NEWPKCS#1]中也定义了相同的RSA加密方案。在RFC 2437中，此RSA加密方案称为RSAES-PKCS1-v1_5。
This section specifies the conventions employed by CMS implementations that support symmetric key-encryption key management using Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2 128-bit keys MUST 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-encryptionalgorithms. For example, a 40-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption key.
本节规定了CMS实施所采用的约定，这些实施支持使用三重DES或RC2密钥加密密钥的对称密钥加密密钥管理。支持RC2时，RC2 128位密钥必须用作密钥加密密钥，并且必须与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. 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. However, only key agreement algorithms that inherently provide authentication ought to be used with AuthenticatedData. 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 KeyAgreeRecipientInfo keyEncryptionAlgorithm和AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm字段的KeyWrapAlgorithm参数中。但是，只有本质上提供身份验证的密钥协商算法才能用于AuthenticatedData。包装的内容加密密钥位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey字段中，包装的消息身份验证密钥位于AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey字段中。
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 a 168-bit Triple-DES key-encryption key.
CMS实现可能支持混合密钥加密和内容加密算法。例如，128位RC2内容加密密钥可以用168位三重DES密钥加密密钥包装。
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 3.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified in section 3.2 of RFC 3217 [WRAP].
RFC 3217[wrap]第3.1节规定了用于使用三重DES密钥加密密钥加密三重DES内容加密密钥的密钥包裹算法。RFC 3217[WRAP]第3.2节规定了相应的密钥展开算法。
Out-of-band distribution of the Triple-DES key-encryption key used to encrypt the Triple-DES content-encryption key is beyond the scope of this document.
用于加密三重DES内容加密密钥的三重DES密钥加密密钥的带外分发超出了本文档的范围。
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 a 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with a 128-bit RC2 key-encryption key.
CMS实现可能支持混合密钥加密和内容加密算法。例如，128位RC2内容加密密钥可以用168位三重DES密钥加密密钥包装。类似地，40位RC2内容加密密钥可以用128位RC2密钥加密密钥包装。
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）编码表示负数。
RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58.
RC2 128位密钥必须用作密钥加密密钥，并且必须与RC2ParameterVersion参数设置为58一起使用。
The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2 key-encryption key is specified in section 4.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified 4.2 of RFC 3217 [WRAP].
RFC 3217[wrap]第4.1节规定了用于使用RC2密钥加密密钥加密RC2内容加密密钥的密钥包裹算法。RFC 3217[WRAP]第4.2节规定了相应的密钥展开算法。
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密钥加密密钥的带外分发超出了本文档的范围。
This section specifies the conventions employed by CMS implementations that support password-based key management using PBKDF2.
本节规定了CMS实现采用的约定，这些约定支持使用PBKDF2进行基于密码的密钥管理。
Key derivation algorithms are used to convert a password into a key-encryption key as part of the password-based key management technique.
密钥派生算法用于将密码转换为密钥加密密钥，作为基于密码的密钥管理技术的一部分。
Key derivation algorithm identifiers are located in the EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm fields.
密钥派生算法标识符位于EnvelopedData RecipientInfos PasswordRecipientInfo关键字派生算法M和Authenticated Data RecipientInfos PasswordRecipientInfo关键字派生算法M字段中。
The key-encryption key that is derived from the password is used to encrypt the content-encryption key.
从密码派生的密钥加密密钥用于加密内容加密密钥。
The content-encryption keys encrypted with password-derived key-encryption keys are located in the EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey field. The message-authentication keys encrypted with password-derived key-encryption keys are located in the AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.
使用密码衍生密钥加密密钥加密的内容加密密钥位于EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey字段中。使用密码派生密钥加密密钥加密的消息身份验证密钥位于AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey字段中。
The PBKDF2 key derivation algorithm is specified in RFC 2898 [PKCS#5]. The KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and any associated parameters used to derive the key-encryption key from the user-supplied password. The algorithm identifier for the PBKDF2 key derivation algorithm is:
RFC 2898[PKCS#5]中规定了PBKDF2密钥推导算法。KeyDerivationGorithMidentifer标识密钥派生算法，以及用于从用户提供的密码派生密钥加密密钥的任何相关参数。PBKDF2密钥派生算法的算法标识符为：
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
The AlgorithmIdentifier parameter field MUST be PBKDF2-params:
AlgorithmIdentifier参数字段必须是PBKDF2参数：
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
Within the PBKDF2-params, the salt MUST use the specified OCTET STRING.
在PBKDF2参数中，salt必须使用指定的八位字节字符串。
5 Content Encryption Algorithms
5种内容加密算法
This section specifies the conventions employed by CMS implementations that support content encryption using Three-Key Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC mode.
本节规定了CMS实施所采用的约定，这些约定支持在CBC模式下使用三密钥三重DES、在CBC模式下使用两密钥三重DES或在CBC模式下使用RC2进行内容加密。
Content encryption algorithm 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 a 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）编码表示负数。
6 Message Authentication Code Algorithms
6消息认证码算法
This section specifies the conventions employed by CMS implementations that support the HMAC with SHA-1 message authentication code (MAC).
本节规定了CMS实施所采用的约定，这些约定支持带有SHA-1消息认证码（MAC）的HMAC。
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 }
There are two possible encodings for the HMAC with SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for the AlgorithmIdentifier type was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations may encode parameters as a NULL while others omit them entirely.
使用SHA-1算法标识符参数字段对HMAC进行两种可能的编码。这两个备选方案产生于这样一个事实：当1988年算法识别器类型的语法被翻译成1997年的语法时，与算法识别器参数相关的可选语法丢失了。后来通过缺陷报告恢复了可选的，但那时许多人认为算法参数是强制性的。由于这种历史，一些实现可能将参数编码为空，而另一些实现则完全忽略它们。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate HMAC with SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifier参数字段是可选的。如果存在，参数字段必须包含空值。实现必须接受HMAC和SHA-1算法标识符，且不包含参数。实现必须接受HMAC和带有空参数的SHA-1算法标识符。实现应该使用SHA-1算法标识符生成HMAC，该标识符没有参数。
7 ASN.1 Module
7 ASN.1模块
CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } ;
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } ;
-- 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 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 }
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 }
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
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-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
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 }
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
-- Public Key Types
--公钥类型
Dss-Pub-Key ::= INTEGER -- Y
Dss-Pub-Key ::= INTEGER -- Y
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
DHPublicKey ::= INTEGER -- y = g^x mod p
DHPublicKey ::= INTEGER -- y = g^x mod p
-- Signature Value Types
--签名值类型
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
-- Algorithm Identifier Parameter Types
--算法标识符参数类型
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
DHDomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
DHDomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
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
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
END -- of CryptographicMessageSyntaxAlgorithms
END -- of CryptographicMessageSyntaxAlgorithms
8 References
8参考文献
[3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[3DES]美国国家标准协会。ANSI X9.52-1998，三重数据加密算法操作模式。1998
[CERTALGS] Bassham, L., Housley, R. and W. Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[CERTALGS]Bassham，L.，Housley，R.和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3269, August 2002.
[CMS]Housley，R.，“加密消息语法”，RFC 3269，2002年8月。
[DES] American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983.
[DES]美国国家标准协会。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日。
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，“HMAC：用于消息认证的键控哈希”，RFC2104，1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[MMA] Rescorla, E., "Preventing the Million Message Attack on CMS", RFC 3218, January 2002.
[MMA]Rescorla，E.“防止CMS上的百万消息攻击”，RFC 3218，2002年1月。
[MODES] National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
[模式]国家标准与技术研究所。FIPS Pub 81:DES操作模式。1980年12月2日。
[NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Encryption, Version 2.0, RFC 2437, October 1998.
[NEWPKCS#1]Kaliski，B.和J.Staddon，“PKCS#1:RSA加密，2.0版，RFC 2437，1998年10月。
[OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[OLDCMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[PKCS#1] Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October, 1998.
[PKCS#1]Kaliski，B，“PKCS#1:RSA加密，2.0版”，RFC 2437，1998年10月。
[PKCS#5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification", RFC 2898, September 2000.
[PKCS#5]Kaliski，B.，“PKCS#5：基于密码的加密规范”，RFC 28982000年9月。
[PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[简介]Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 32802002年4月。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security, RFC 1750, December 1994.
[随机]Eastlake，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[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日。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[WRAP]Housley，R.，“三重DES和RC2键包装”，RFC 3217，2001年12月。
[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
9 Security Considerations
9安全考虑
The CMS provides a method for digitally signing data, digesting data, encrypting data, and authenticating data. This document identifies the conventions for using several cryptographic algorithms for use with the CMS.
CMS提供了一种对数据进行数字签名、数据摘要、数据加密和数据认证的方法。本文件确定了在CMS中使用几种加密算法的约定。
Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade.
实现必须保护签名者的私钥。签名者私钥的泄露允许伪装。
Implementations must protect the key management private key, the key-encryption key, and the content-encryption key. Compromise of the key management private key or the key-encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the content-encryption key may result in disclosure of the associated encrypted content.
实现必须保护密钥管理私钥、密钥加密密钥和内容加密密钥。密钥管理私钥或密钥加密密钥的泄露可能导致该密钥保护的所有内容被泄露。类似地，内容加密密钥的泄露可能导致相关加密内容的泄露。
Implementations must protect the key management private key and the message-authentication key. Compromise of the key management private key permits masquerade of authenticated data. Similarly, compromise of the message-authentication key may result in undetectable modification of the authenticated content.
实现必须保护密钥管理私钥和消息身份验证密钥。密钥管理私钥的泄露允许伪装经过身份验证的数据。类似地，消息认证密钥的泄露可能导致认证内容的不可检测的修改。
The key management technique employed to distribute message-authentication keys must itself provide authentication, otherwise the content is delivered with integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary data origin authentication when both the originator and recipient public keys are bound to appropriate identities in X.509 certificates [PROFILE].
用于分发消息身份验证密钥的密钥管理技术本身必须提供身份验证，否则将从未知源完整地交付内容。RSA[PKCS#1，NEWPKCS#1]和短暂静态Diffie-Hellman[DH-X9.42]均未提供必要的数据源身份验证。静态Diffie-Hellman[DH-X9.42]在发端人和接收方公钥都绑定到X.509证书[PROFILE]中的适当身份时，提供了必要的数据源身份验证。
When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties.
当两个以上的参与方共享同一消息身份验证密钥时，不提供数据源身份验证。知道消息身份验证密钥的任何一方都可以计算有效的MAC，因此内容可能来自任何一方。
Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), one-time values (such as the k value when generating a DSA signature), 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 such values 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）、一次性值（例如生成DSA签名时的k值）和填充。此外，公钥/私钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密的此类值可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 1750[RANDOM]在这方面提供了重要的指导，FIPS Pub 186[DSS]的附录3提供了一种高质量的PRNG技术。
When using key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with 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对内容进行加密，并且使用40位RC2密钥包装Triple-DES内容加密密钥，则最多提供40位保护。确定40位RC2密钥值的简单搜索可以恢复三重DES密钥，然后可以使用三重DES密钥解密内容。因此，实现者必须确保密钥加密算法与内容加密算法一样强大。
RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key-encryption key [RC2]. The key wrap algorithms makes use of CBC mode [MODES]. These key wrap algorithms have been reviewed for use with Triple-DES 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.
RFC 3217[WRAP]指定用于使用三重DES密钥加密密钥[3DES]加密三重DES内容加密密钥或使用RC2密钥加密密钥[RC2]加密RC2内容加密密钥的密钥包裹算法。密钥包裹算法使用CBC模式[模式]。这些密钥封装算法已被审查用于三重DES和RC2。尚未审查它们是否与其他加密模式或其他加密算法一起使用。因此，如果CMS实现希望支持除三重DES或RC2之外的密码，则需要定义额外的密钥包裹算法以支持额外的密码。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis 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 to regularly update the set of algorithms in their implementations.
算法的实现应该是模块化的，这样就可以很容易地插入新的算法。也就是说，实现者应该准备好在他们的实现中定期更新算法集。
Users of the CMS, particularly those employing the CMS to support interactive applications, should be aware that RSA (PKCS #1 v1.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 the 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]中规定的RSA（PKCS#1 v1.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 updated document supersedes 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 algorithm 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算法规范的未来版本中。
See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.
有关在PKCS#1 1.5版实现中阻止自适应选择密文漏洞的更多信息，请参阅RFC 3218[MMA]。
10 Acknowledgments
10致谢
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave Solo for their efforts and support.
本文件是许多专业人士贡献的成果。我感谢IETF S/MIME工作组所有成员的辛勤工作。我特别感谢Rich Ankney、Simon Blake Wilson、Tim Dean、Steve Dusse、Carl Ellison、Peter Gutmann、Bob Jueneman、Stephen Henson、Paul Hoffman、Scott Hollenbeck、Don Johnson、Burt Kaliski、John Linn、John Pawling、Blake Ramsdell、Francois Rousseau、Jim Schaad和Dave Solo的努力和支持。
11 Author Address
11作者地址
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 EMail: rhousley@rsasecurity.com
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon，弗吉尼亚州20170电子邮件：rhousley@rsasecurity.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。