Network Working Group J. Schaad
Request for Comments: 3565 Soaring Hawk Consulting
Category: Standards Track July 2003
Network Working Group J. Schaad
Request for Comments: 3565 Soaring Hawk Consulting
Category: Standards Track July 2003
Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)
在加密消息语法（CMS）中使用高级加密标准（AES）加密算法
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS).
本文件规定了使用高级加密标准（AES）算法对加密消息语法（CMS）进行加密的约定。
Conventions used in this document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[必须]中的说明进行解释。
This document specifies the conventions for using Advanced Encryption Standard (AES) content encryption algorithm with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types.
本文件规定了使用高级加密标准（AES）内容加密算法和加密消息语法[CMS]封装数据和加密数据内容类型的约定。
CMS values are generated using ASN.1 [X.208-88], using the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
CMS值是使用ASN.1[X.208-88]，使用基本编码规则（BER）[X.209-88]和可分辨编码规则（DER）[X.509-88]生成的。
The Advanced Encryption Standard (AES) [AES] was developed to replace DES [DES]. The AES Federal Information Processing Standard (FIPS) Publication specifies a cryptographic algorithm for use by U.S. Government organizations. However, the AES will also be widely used by organizations, institutions, and individuals outside of the U.S. Government.
开发高级加密标准（AES）[AES]是为了取代DES[DES]。AES联邦信息处理标准（FIPS）出版物规定了供美国政府机构使用的加密算法。但是，AES也将被美国政府以外的组织、机构和个人广泛使用。
Two researchers who developed and submitted the Rijndael algorithm for consideration are both cryptographers from Belgium: Dr. Joan Daemen of Proton World International and Dr. Vincent Rijmen, a postdoctoral researcher in the Electrical Engineering Department of Katholieke Universiteit Leuven.
开发并提交Rijndael算法供考虑的两名研究人员都是比利时的密码学家：质子世界国际公司的Joan Daemen博士和鲁汶Katholieke大学电气工程系的博士后Vincent Rijmen博士。
The National Institute of Standards and technology (NIST) selected the Rijndael algorithm for AES because it offers a combination of security, performance, efficiency, ease of implementation, and flexibility. Specifically, Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. The very low memory requirements of the Rijndael algorithm make it very well suited for restricted-space environments, in which it also demonstrates excellent performance. The Rijndael algorithm operations are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting the algorithm's performance. Finally, the algorithm's internal round structure appears to have good potential to benefit from instruction-level parallelism.
国家标准与技术研究所（NIST）选择Rijndael算法用于AES，因为它提供了安全性、性能、效率、易于实现和灵活性的组合。具体而言，Rijndael在各种计算环境中，无论是在反馈模式还是非反馈模式下使用，在硬件和软件方面都始终表现出色。它的关键设置时间非常好，关键灵活性也很好。Rijndael算法非常低的内存需求使其非常适合受限空间环境，在受限空间环境中，它还表现出优异的性能。Rijndael算法操作是最容易抵御电源和定时攻击的操作之一。此外，似乎可以在不显著影响算法性能的情况下针对此类攻击提供一些防御。最后，该算法的内部圆形结构似乎有很好的潜力从指令级并行性中获益。
The AES specifies three key sizes: 128, 192 and 256 bits.
AES指定了三种密钥大小：128、192和256位。
The CMS enveloped-data content type consists of encrypted content and wrapped content-encryption keys for one or more recipients. The AES algorithm is used to encrypt the content.
CMS信封数据内容类型由一个或多个收件人的加密内容和包装内容加密密钥组成。AES算法用于加密内容。
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 6, "Enveloped-data Content Type".
合规软件必须满足[CMS]第6节“封装数据内容类型”中规定的构建封装数据内容类型的要求。
The AES content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. The content-encryption key (CEK) is used to encrypt the content.
必须为封装数据内容类型的每个实例随机生成AES内容加密密钥。内容加密密钥（CEK）用于加密内容。
AES can be used with the enveloped-data content type using any of the following key management techniques defined in [CMS] Section 6.
AES可使用[CMS]第6节中定义的以下任何关键管理技术与封装数据内容类型一起使用。
1) Key Transport: The AES CEK is uniquely wrapped for each recipient using the recipient's public RSA key and other values. Section 2.2 provides additional details.
1) 密钥传输：AES CEK使用收件人的公钥和其他值为每个收件人进行唯一包装。第2.2节提供了其他详细信息。
2) Key Agreement: The AES CEK is uniquely wrapped for each recipient using a pairwise symmetric key-encryption key (KEK) generated using an originator's randomly generated private key (ES-DH [DH]) or previously generated private key (SS-DH [DH]), the recipient's public DH key, and other values. Section 2.3 provides additional details.
2) 密钥协议：AES CEK使用成对对称密钥加密密钥（KEK）为每个收件人进行唯一包装，KEK使用发起者随机生成的私钥（ES-DH[DH]）或先前生成的私钥（SS-DH[DH]）、收件人的公共DH密钥和其他值生成。第2.3节提供了其他详细信息。
3) Previously Distributed Symmetric KEK: The AES CEK is wrapped using a previously distributed symmetric KEK (such as a Mail List Key). The methods by which the symmetric KEK is generated and distributed are beyond the scope of this document. Section 2.4 provides additional details.
3) 先前分布的对称KEK：AES CEK使用先前分布的对称KEK（例如邮件列表密钥）进行包装。生成和分发对称KEK的方法超出了本文档的范围。第2.4节提供了其他详细信息。
4) Password Encryption: The AES CEK is wrapped using a KEK derived from a password or other shared secret. Section 2.5 provides additional details.
4) 密码加密：AES CEK使用从密码或其他共享秘密派生的KEK进行包装。第2.5节提供了其他详细信息。
Documents defining the use of the Other Recipient Info structure will need to define the proper use for the AES algorithm if desired.
如果需要，定义使用其他收件人信息结构的文档需要定义AES算法的正确用法。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as follows:
封装的数据内容类型是使用EnvelopedData语法进行ASN.1编码的。EnvelopedData语法的字段必须按如下方式填充：
The EnvelopedData version is determined based on a number of factors.
EnvelopedData版本是根据许多因素确定的。
See [CMS] section 6.1 for the algorithm to determine this value.
有关确定该值的算法，请参见[CMS]第6.1节。
The EnvelopedData recipientInfos CHOICE is dependent on the key management technique used. Section 2.2, 2.3, 2.4 and 2.5 provide additional information.
EnvelopedData recipientInfos的选择取决于所使用的关键管理技术。第2.2、2.3、2.4和2.5节提供了附加信息。
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm. Implementations MUST support content encryption with AES, but implementations MAY support other algorithms as well.
EnvelopedData encryptedContentInfo contentEncryptionAlgorithm字段必须指定对称加密算法。实现必须支持AES的内容加密，但实现也可能支持其他算法。
The EnvelopedData unprotectedAttrs MAY be present.
可能存在未受保护的信封数据。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as follows:
封装的数据内容类型是使用EnvelopedData语法进行ASN.1编码的。EnvelopedData语法的字段必须按如下方式填充：
The KeyTransRecipientInfo version MUST be either 0 or 2. If the RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 0. If the RecipientIdentifier is subjectKeyIdentifier, then the version MUST be 2.
KeyTransRecipientInfo版本必须为0或2。如果RecipientIdentifier是选项issuerAndSerialNumber，则版本必须为0。如果RecipientIdentifier是subjectKeyIdentifier，则版本必须为2。
The KeyTransRecipientInfo RecipientIdentifier provides two alternatives for specifying the recipient's certificate, and thereby the recipient's public key. The recipient's certificate MUST contain a RSA public key. The CEK is encrypted with the recipient's RSA 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.
KeyTransRecipientInfo RecipientIdentifier提供了两种方法来指定收件人的证书，从而指定收件人的公钥。收件人的证书必须包含RSA公钥。CEK使用收件人的RSA公钥进行加密。发卡机构序列号备选方案通过发卡机构的可分辨名称和证书序列号识别收件人的证书；subjectKeyIdentifier通过X.509 subjectKeyIdentifier扩展值标识收件人的证书。
The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the key transport algorithm (i.e., RSAES-OAEP [RSA-OAEP]), and the associated parameters used to encrypt the CEK for the recipient.
KeyTransRecipientInfo keyEncryptionAlgorithm字段指定密钥传输算法（即RSAES-OAEP[RSA-OAEP]）以及用于加密接收方CEK的相关参数。
The KeyTransRecipientInfo encryptedKey is the result of encrypting the CEK with the recipient's RSA public key.
KeyTransRecipientInfo encryptedKey是使用收件人的RSA公钥加密CEK的结果。
This section describes the conventions for using ES-DH or SS-DH and AES with the CMS enveloped-data content type to support key agreement. When key agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE MUST be used.
本节介绍使用ES-DH或SS-DH和AES以及CMS封装数据内容类型来支持密钥协商的约定。使用密钥协议时，必须使用RecipientInfo密钥协议RecipientInfo选项。
The KeyAgreeRecipient version MUST be 3.
密钥收件人版本必须为3。
The EnvelopedData originatorInfo field MUST be the originatorKey alternative. The originatorKey algorithm fields MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey MUST contain the originator's ephemeral public key.
EnvelopedData originatorInfo字段必须是originatorKey替代项。原始工作算法字段必须包含缺少参数的dh public number对象标识符。发起人公钥必须包含发起人的临时公钥。
The EnvelopedData ukm MAY be present.
可能存在信封数据ukm。
The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH algorithm identifier [CMSALG].
EnvelopedData KeyEncryontalGorithm必须是id alg ESDH算法标识符[CMSALG]。
Generation of the AES KEK to be used with the AES-key wrap algorithm is done using the method described in [DH].
使用[DH]中描述的方法生成与AES密钥包裹算法一起使用的AES KEK。
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZ是10 11 12 13的20字节00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
The key wrap algorithm is AES-128 wrap, so we need 128 bits (16 bytes) of keying material.
密钥包裹算法是AES-128包裹，因此我们需要128位（16字节）的密钥材料。
No partyAInfo is used.
没有使用PartyInfo。
Consequently, the input to SHA-1 is:
因此，SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 1b 30 11 06 09 60 86 48 01 65 03 04 01 05 ; AES-128 wrap OID 04 04 00 00 00 01 ; Counter a2 06 04 04 00 00 00 80 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ 30 1b 30 11 06 09 60 86 48 01 65 03 04 01 05；AES-128包装OID 04 00 01；柜台a2 06 04 00 00 80；键长
And the output is the 32 bytes:
输出为32字节：
d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9
d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9
Consequently,
因此
K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64
K=d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZ是10 11 12 13的20字节00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32 bytes) of keying material.
密钥封装算法是AES-256密钥封装，因此我们需要256位（32字节）的密钥材料。
The partyAInfo used is the 64 bytes
使用的partyAInfo是64字节
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 89 ab cd ef fe dc ba 98 54 32 01
Consequently, the input to first invocation of SHA-1 is:
因此，第一次调用SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d ; AES-256 wrap OID 04 04 00 00 00 01 ; Counter a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d；AES-256包裹OID 04 04 00 01；计数器a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01；partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00 ; key length
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 00 01 00；键长
And the output is the 20 bytes:
输出为20个字节：
88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93
88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93
The input to second invocation of SHA-1 is:
第二次调用SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d ; AES-256 wrap OID 04 04 00 00 00 02 ; Counter a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ 30 5f 30 11 06 09 60 86 48 01 65 03 04 01 2d；AES-256包装OID 04 04 00 02；计数器a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01；partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 01 00 ; key length
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 00 01 00；键长
And the output is the 20 bytes:
输出为20个字节：
CB A8 F9 22 BD 1B 56 A0 71 C9 6F 90 36 C6 04 2C AA 20 94 37
CB A8 F9 22 BD 1B 56 A0 71 C9 6F 90 36 C6 04 2C AA 20 94 37
Consequently,
因此
K = 88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 CB A8 F9 22 BD 1B 56 A0
K=88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93 CB A8 F9 22 BD 1B 56 A0
The AES key wrap algorithm encrypts one AES key in another AES key. The algorithm produces an output 64-bits longer than the input AES CEK, the additional bits are a checksum. The algorithm uses 6*n AES encryption/decryption operations where n is number of 64-bit blocks in the AES CEK. Full details of the AES key wrap algorithm are available at [AES-WRAP].
AES密钥包裹算法将一个AES密钥加密到另一个AES密钥中。该算法产生的输出比输入AES CEK长64位，额外的位是校验和。该算法使用6*n AES加密/解密操作，其中n是AES CEK中的64位块数。有关AES密钥包裹算法的详细信息，请访问[AES-wrap]。
NIST has assigned the following OIDs to define the AES key wrap algorithm.
NIST已指定以下OID来定义AES密钥包裹算法。
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
In all cases the parameters field MUST be absent. The OID gives the KEK key size, but does not make any statements as to the size of the wrapped AES CEK. Implementations MAY use different KEK and CEK
在所有情况下，参数字段都必须不存在。OID给出了KEK密钥的大小，但没有对封装的AES CEK的大小做出任何声明。实现可能使用不同的KEK和CEK
sizes. Implements MUST support the CEK and the KEK having the same length. If different lengths are supported, the KEK MUST be of equal or greater length than the CEK.
尺寸。机具必须支持长度相同的CEK和KEK。如果支持不同的长度，KEK的长度必须等于或大于CEK。
This section describes the conventions for using AES with the CMS enveloped-data content type to support previously distributed symmetric KEKs. When a previously distributed symmetric KEK is used to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo CHOICE MUST be used. The methods used to generate and distribute the symmetric KEK are beyond the scope of this document. One possible method of distributing keys is documented in [SYMKEYDIST].
本节描述了将AES与CMS封装数据内容类型一起使用以支持先前分布式对称KEK的约定。当使用先前分布的对称KEK包装AES CEK时，必须使用RecipientInfo-KEKRecipientInfo选项。用于生成和分发对称KEK的方法超出了本文档的范围。[SYMKEYDIST]中记录了一种可能的密钥分发方法。
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section 6.2.3, KEKRecipientInfo Type.
必须按照[CMS]第6.2.3节“KEKRecipientInfo类型”中的规定填充KEKRecipientInfo字段。
The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be one of the OIDs defined in section 2.3.2 indicating that the AES wrap function is used to wrap the AES CEK. The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent.
KEKRecipientInfo keyEncryptionAlgorithm算法字段必须是第2.3.2节中定义的OID之一，表明AES wrap函数用于包装AES CEK。KEKRecipientInfo keyEncryptionAlgorithm参数字段必须不存在。
The KEKRecipientInfo encryptedKey field MUST include the AES CEK wrapped using the previously distributed symmetric KEK as input to the AES wrap function.
KEKRecipientInfo encryptedKey字段必须包含使用先前分发的对称KEK作为AES wrap函数输入而包装的AES CEK。
This section describes the conventions for using AES with the CMS enveloped-data content type to support password-based key management.
本节介绍将AES与CMS封装数据内容类型一起使用以支持基于密码的密钥管理的约定。
When a password derived KEK is used to wrap the AES CEK, then the RecipientInfo PasswordRecipientInfo CHOICE MUST be used.
当使用密码派生的KEK包装AES CEK时，必须使用RecipientInfo密码RecipientInfo选项。
The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs defined in section 2.3.2 indicating the AES wrap function is used to wrap the AES CEK. The keyEncryptionAlgorithm parameters field MUST be absent.
keyEncryptionAlgorithm算法字段必须是第2.3.2节中定义的OID之一，表明AES wrap函数用于包装AES CEK。keyEncryptionAlgorithm参数字段必须不存在。
The encryptedKey field MUST be the result of the AES key wrap algorithm applied to the AES CEK value.
encryptedKey字段必须是应用于AES CEK值的AES密钥包裹算法的结果。
The CMS encrypted-data content type consists of encrypted content with implicit key management. The AES algorithm is used to encrypt the content.
CMS加密数据内容类型由具有隐式密钥管理的加密内容组成。AES算法用于加密内容。
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 8, "Encrypted-data Content Type".
合规软件必须满足[CMS]第8节“加密数据内容类型”中规定的构建封装数据内容类型的要求。
The encrypted-data content type is ASN.1 encoded using the EncryptededData syntax. The fields of the EncryptedData syntax MUST be populated as follows:
加密的数据内容类型是使用EncryptedData语法进行ASN.1编码的。EncryptedData语法的字段必须按如下方式填充：
The EncryptedData version is determined based on a number of factors.
EncryptedData版本取决于多个因素。
See [CMS] section 9.1 for the algorithm to determine this value.
有关确定该值的算法，请参见[CMS]第9.1节。
The EncryptedData encryptedContentInfo contentEncryptionAlgorithm field MUST specify a symmetric encryption algorithm. Implementations MUST support encryption using AES, but implementations MAY support other algorithms as well.
EncryptedData encryptedContentInfo contentEncryptionAlgorithm字段必须指定对称加密算法。实现必须支持使用AES的加密，但实现也可能支持其他算法。
The EncryptedData unprotectedAttrs MAY be present.
可能存在未受保护的加密数据。
This section specified algorithm identifiers for the AES encryption algorithm.
本节指定了AES加密算法的算法标识符。
The AES algorithm is defined in [AES]. RSAES-OAEP [RSA-OAEP] MAY be used to transport AES keys.
AES算法在[AES]中定义。RSAES-OAEP[RSA-OAEP]可用于传输AES密钥。
AES is added to the set of symmetric content encryption algorithms defined in [CMSALG]. The AES content-encryption algorithm, in Cipher Block Chaining (CBC) mode, for the three different key sizes are identified by the following object identifiers:
AES被添加到[CMSALG]中定义的对称内容加密算法集中。在密码块链接（CBC）模式下，三种不同密钥大小的AES内容加密算法由以下对象标识符标识：
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a AES-IV:
AlgorithmIdentifier parameters字段必须存在，并且parameters字段必须包含AES-IV：
AES-IV ::= OCTET STRING (SIZE(16))
AES-IV ::= OCTET STRING (SIZE(16))
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 encrypt the content located in the EnvelopedData EncryptedContentInfo encryptedContent and the EncryptedData EncryptedContentInfo encryptedContent fields.
内容加密算法用于加密EnvelopedData EncryptedContentInfo encryptedContent和EncryptedData EncryptedContentInfo encryptedContent字段中的内容。
An S/MIME client SHOULD announce the set of cryptographic functions it supports by using the S/MIME capabilities attribute. This attribute provides a partial list of object identifiers of cryptographic functions and MUST be signed by the client. The algorithm OIDs SHOULD be logically separated in functional categories and MUST be ordered with respect to their preference.
S/MIME客户端应通过使用S/MIME capabilities属性来宣布其支持的加密函数集。此属性提供加密函数的对象标识符的部分列表，并且必须由客户端签名。算法OID应在功能类别中进行逻辑分离，并且必须根据其偏好进行排序。
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support.
RFC 2633[MSG]，第2.5.2节定义了SMIMECapabilities签名属性（定义为SMIMECapabilities序列），用于指定宣布SMIMECapabilities的软件可以支持的算法的部分列表。
If an S/MIME client is required to support symmetric encryption with AES, the capabilities attribute MUST contain the AES object identifier specified above in the category of symmetric algorithms. The parameter with this encoding MUST be absent.
如果要求S/MIME客户端支持AES的对称加密，则“能力”属性必须包含上述对称算法类别中指定的AES对象标识符。必须缺少具有此编码的参数。
The encodings for the mandatory key sizes are:
强制密钥大小的编码为：
Key Size Capability 128 30 0B 06 09 60 86 48 01 65 03 04 01 02 196 30 0B 06 09 60 86 48 01 65 03 04 01 16 256 30 0B 06 09 60 86 48 01 65 03 04 01 2A
密钥大小功能128 30 0B 06 09 60 86 48 01 65 03 04 01 02 196 30 0B 06 09 60 86 48 01 65 03 04 01 16 256 30 0B 06 09 60 86 48 01 65 03 04 01 2A
When a sending agent creates an encrypted message, it has to decide which type of encryption algorithm to use. In general the decision process involves information obtained from the capabilities lists included in messages received from the recipient, as well as other information such as private agreements, user preferences, legal restrictions, and so on. If users require AES for symmetric encryption, the S/MIME clients on both the sending and receiving side MUST support it, and it MUST be set in the user preferences.
当发送代理创建加密消息时，它必须决定使用哪种类型的加密算法。一般来说，决策过程涉及从收件人收到的消息中包含的功能列表中获得的信息，以及其他信息，如私人协议、用户偏好、法律限制等。如果用户需要AES进行对称加密，则发送端和接收端的S/MIME客户端都必须支持AES，并且必须在用户首选项中设置AES。
If RSA-OAEP [PKCS#1v2.0] and RSA PKCS #1 v1.5 [PKCS#1v1.5] are both used to transport the same CEK, then an attacker can still use the Bleichenbacher attack against the RSA PKCS #1 v1.5 encrypted key. It is generally unadvisable to mix both RSA-OAEP and RSA PKCS#1 v1.5 in the same set of recipients.
如果RSA-OAEP[PKCS#1v2.0]和RSA PKCS#1v1.5[PKCS#1v1.5]都用于传输相同的CEK，那么攻击者仍然可以对RSA PKCS#1v1.5加密密钥使用Bleichenbacher攻击。在同一组收件人中混合使用RSA-OAEP和RSA PKCS#1 v1.5通常是不明智的。
Implementations must protect the RSA private key and the CEK. Compromise of the RSA private key may result in the disclosure of all messages protected with that key. Compromise of the CEK may result in disclosure of the associated encrypted content.
实施必须保护RSA私钥和CEK。RSA私钥的泄露可能会导致使用该密钥保护的所有消息被泄露。CEK的泄露可能导致相关加密内容的泄露。
The generation of AES CEKs relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these 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.
AES CEK的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成这些值可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 1750[随机]在这方面提供了重要的指导。
When wrapping a CEK with a KEK, the KEK MUST always be at least the same length as the CEK. An attacker will generally work at the weakest point in an encryption system. This would be the smaller of the two key sizes for a brute force attack.
用桶包装CEK时，桶的长度必须至少与CEK相同。攻击者通常会在加密系统的最薄弱点工作。这将是暴力攻击的两个关键尺寸中较小的一个。
Normative References
规范性引用文件
[AES] National Institute of Standards. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]国家标准协会。FIPS Pub 197：高级加密标准（AES）。2001年11月26日。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 3369，2002年8月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms, RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[DES] National Institute of Standards and Technology. FIPS Pub 46: Data Encryption Standard. 15 January 1977.
[DES]国家标准与技术研究所。FIPS Pub 46：数据加密标准。1977年1月15日。
[DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[DH]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RSA-OAEP] Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RSA-OAEP]Housley，R.“在加密消息语法（CMS）中使用RSAES-OAEP密钥传输算法”，RFC 3560，2003年7月。
[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.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88]CCITT。建议X.509：目录认证框架。1988
Informational References
参考资料
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG]Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[PKCS#1v1.5] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, March 1998.
[PKCS#1v1.5]Kaliski，B.，“PKCS#1:RSA加密，1.5版”，RFC 2313，1998年3月。
[PKCS#1v2.0] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998.
[PKCS#1v2.0]Kaliski，B.，“PKCS#1:RSA加密，2.0版”，RFC 2437，1998年10月。
[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月。
[SYMKEYDIST] Turner, S., "CMS Symmetric Key Management and Distribution", Work in Progress, January 2003.
[SYMKEYDIST]Turner，S.，“CMS对称密钥管理和分发”，正在进行的工作，2003年1月。
Acknowledgements
致谢
This document is the result of contributions from many professionals. We appreciate the hard work of all members of the IETF S/MIME Working Group.
本文件是许多专业人士贡献的成果。我们感谢IETF S/MIME工作组所有成员的辛勤工作。
Appendix A ASN.1 Module
附录A ASN.1模块
CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) }
CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- PKIX
AlgorithmIdentifier
FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)};
-- EXPORTS ALL --
IMPORTS
-- PKIX
AlgorithmIdentifier
FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)};
-- AES information object identifiers --
--AES信息对象标识符--
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 }
-- AES using CBC-chaining mode for key sizes of 128, 192, 256
--AES使用CBC链接模式，密钥大小为128、192、256
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
-- AES-IV is a the parameter for all the above object identifiers.
--AES-IV是上述所有对象标识符的参数。
AES-IV ::= OCTET STRING (SIZE(16))
AES-IV ::= OCTET STRING (SIZE(16))
-- AES Key Wrap Algorithm Identifiers - Parameter is absent
--AES密钥包裹算法标识符-缺少参数
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
END
终止
Author's Address
作者地址
Jim Schaad Soaring Hawk Consulting
吉姆·沙德·霍克咨询公司
EMail: jimsch@exmsft.com
EMail: jimsch@exmsft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。