Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6318 Vigil Security
Obsoletes: 5008 J. Solinas
Category: Informational National Security Agency
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6318 Vigil Security
Obsoletes: 5008 J. Solinas
Category: Informational National Security Agency
ISSN: 2070-1721 June 2011
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
安全/多用途Internet邮件扩展（S/MIME）中的套件B
Abstract
摘要
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008.
本文件规定了在RFC 5751中规定的安全/多用途互联网邮件扩展（s/MIME）中使用美国国家安全局套件B算法的约定。本文件淘汰了RFC 5008。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6318.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6318.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 ......................................................4
1.3. Suite B Security Levels ....................................4
2. SHA-256 and SHA-384 Message Digest Algorithms ...................5
3. ECDSA Signature Algorithm .......................................6
4. Key Management ..................................................7
4.1. ECDH Key Agreement Algorithm ...............................7
4.2. AES Key Wrap ...............................................8
4.3. Key Derivation Functions ...................................9
5. AES CBC Content Encryption .....................................11
6. Security Considerations ........................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 ......................................................4
1.3. Suite B Security Levels ....................................4
2. SHA-256 and SHA-384 Message Digest Algorithms ...................5
3. ECDSA Signature Algorithm .......................................6
4. Key Management ..................................................7
4.1. ECDH Key Agreement Algorithm ...............................7
4.2. AES Key Wrap ...............................................8
4.3. Key Derivation Functions ...................................9
5. AES CBC Content Encryption .....................................11
6. Security Considerations ........................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
The Fact Sheet on National Security Agency (NSA) Suite B Cryptography [NSA] states:
关于国家安全局（NSA）套件B加密[NSA]的情况介绍指出：
A Cryptographic Interoperability Strategy (CIS) was developed to find ways to increase assured rapid sharing of information both within the U.S. and between the U.S. and her partners through the use of a common suite of public standards, protocols, algorithms and modes referred to as the "Secure Sharing Suite" or S.3. The implementation of CIS will facilitate the development of a broader range of secure cryptographic products which will be available to a wide customer base. The use of selected public cryptographic standards and protocols and Suite B is the core of CIS.
制定了一项加密互操作性战略（CIS），旨在通过使用一套公共标准、协议、算法和模式（称为“安全共享套件”或S.3），找到在美国境内以及在美国与其合作伙伴之间增加有保证的快速信息共享的方法。CIS的实施将促进更广泛的安全加密产品的开发，这些产品将面向广大客户群。选定的公共加密标准和协议以及套件B的使用是CIS的核心。
In 2005, NSA announced Suite B Cryptography which built upon the National Policy on the use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information. In addition to the AES algorithm, Suite B includes cryptographic algorithms for key exchanges, digital signatures and hashing. Suite B cryptography has been selected from cryptography that has been approved by NIST for use by the U.S. Government and specified in NIST standards or recommendations.
2005年，美国国家安全局宣布了基于国家政策的套件B加密技术，即使用高级加密标准（AES）保护国家安全系统和国家安全信息。除了AES算法之外，套件B还包括用于密钥交换、数字签名和散列的加密算法。套件B加密从NIST批准供美国政府使用并在NIST标准或建议中指定的加密中选择。
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms [NSA] in Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME makes use of the Cryptographic Message Syntax (CMS) [CMS]. In particular, the signed-data and the enveloped-data content types are used. This document only addresses Suite B compliance for S/MIME. Other applications of CMS are outside the scope of this document.
本文件规定了在安全/多用途互联网邮件扩展（s/MIME）[MSG]中使用美国国家安全局套件B算法[NSA]的约定。S/MIME使用加密消息语法（CMS）[CMS]。特别地，使用签名数据和封装数据内容类型。本文档仅说明S/MIME的套件B合规性。CMS的其他应用不在本文件范围内。
Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support Suite B.
由于许多套件B算法也可以在其他环境中使用，因此套件B算法所需的大多数约定已在其他文档中指定。本文档引用了这些约定的来源，并重复了一些相关细节，以帮助选择支持Suite B的开发人员。
This specification obsoletes RFC 5008 [SUITEBSMIME]. The primary reason for the publication of this document is to allow greater flexibility in the use of the Suite B Security Levels as discussed in Section 1.3. It also removes some duplication between this document and referenced RFCs.
本规范淘汰了RFC 5008[SuiteBSIME]。发布本文件的主要原因是，如第1.3节所述，允许更灵活地使用套件B安全级别。它还消除了本文件与参考RFC之间的一些重复。
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 RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
CMS values are generated using ASN.1 [X.208-88], 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]生成的。
Suite B offers two suites of algorithms for key agreement, key derivation, key wrap and content encryption, and two possible combinations of hash and signing algorithm. Suite B algorithms are defined to support two minimum levels of cryptographic security: 128 and 192 bits.
套件B提供了两套用于密钥协商、密钥派生、密钥包装和内容加密的算法，以及两种可能的哈希和签名算法组合。套件B算法定义为支持两个最低级别的加密安全性：128位和192位。
For S/MIME signed messages, Suite B follows the direction set by RFC 5753 [CMSECC] and RFC 5754 [SHA2]. Suite B uses these combinations of message digest (hash) and signature functions (Sig Sets):
对于S/MIME签名消息，套件B遵循RFC 5753[CMSECC]和RFC 5754[SHA2]设置的方向。套件B使用消息摘要（哈希）和签名函数（Sig集）的这些组合：
Sig Set 1 Sig Set 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
Sig Set 1 Sig Set 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME encrypted messages, Suite B follows the direction set by RFC 5753 [CMSECC] and follows the conventions set by RFC 3565 [CMSAES].
对于S/MIME加密消息，套件B遵循RFC 5753[CMSECC]设置的方向，并遵循RFC 3565[CMSAES]设置的约定。
Suite B uses these key establishment (KE) algorithms (KE Sets):
套件B使用这些密钥建立（KE）算法（KE集）：
KE Set 1 KE Set 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
KE Set 1 KE Set 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
The two elliptic curves used in Suite B are specified in [DSS], and each appear in the literature under two different names. For the sake of clarity, we list both names below:
套件B中使用的两条椭圆曲线在[DSS]中有规定，并且在文献中以两个不同的名称出现。为了清楚起见，我们在下面列出了这两个名称：
Curve NIST Name SECG Name OID [DSS]
---------------------------------------------------------
nistp256 P-256 secp256r1 1.2.840.10045.3.1.7
nistp384 P-384 secp384r1 1.3.132.0.34
Curve NIST Name SECG Name OID [DSS]
---------------------------------------------------------
nistp256 P-256 secp256r1 1.2.840.10045.3.1.7
nistp384 P-384 secp384r1 1.3.132.0.34
If configured at a minimum level of security of 128 bits, a Suite B compliant S/MIME system performing encryption MUST use either KE Set 1 or KE Set 2, with KE Set 1 being the preferred suite. A digital signature, if applied, MUST use either Sig Set 1 or Sig Set 2, independent of the encryption choice.
如果以128位的最低安全级别配置，则执行加密的符合套件B的S/MIME系统必须使用KE Set 1或KE Set 2，其中KE Set 1是首选套件。如果应用了数字签名，则必须使用Sig Set 1或Sig Set 2，与加密选项无关。
A recipient in an S/MIME system configured at a minimum level of security of 128 bits MUST be able to verify digital signatures from Sig Set 1 and SHOULD be able to verify digital signatures from Sig Set 2.
S/MIME系统中以128位的最低安全级别配置的收件人必须能够验证来自Sig集1的数字签名，并且应该能够验证来自Sig集2的数字签名。
Note that for S/MIME systems configured at a minimum level of security of 128 bits, the algorithm set used for a signed-data content type is independent of the algorithm set used for an enveloped-data content type.
请注意，对于以128位的最低安全级别配置的S/MIME系统，用于签名数据内容类型的算法集独立于用于封装数据内容类型的算法集。
If configured at a minimum level of security of 192 bits, a Suite B compliant S/MIME system performing encryption MUST use KE Set 2. A digital signature, if applied, MUST use Sig Set 2.
如果以192位的最低安全级别配置，则执行加密的符合Suite B的S/MIME系统必须使用KE Set 2。如果应用了数字签名，则必须使用Sig Set 2。
A recipient in an S/MIME system configured at a minimum level of security of 192 bits MUST be able to verify digital signatures from Sig Set 2.
在S/MIME系统中，以192位的最低安全级别配置的收件人必须能够验证来自Sig集合2的数字签名。
SHA-256 and SHA-384 are the Suite B message digest algorithms. RFC 5754 [SHA2] specifies the conventions for using SHA-256 and SHA-384 with the Cryptographic Message Syntax (CMS). Suite B compliant S/MIME implementations MUST follow the conventions in RFC 5754. Relevant details are repeated below.
SHA-256和SHA-384是套件B消息摘要算法。RFC 5754[SHA2]规定了将SHA-256和SHA-384与加密消息语法（CMS）一起使用的约定。与套件B兼容的S/MIME实现必须遵循RFC 5754中的约定。有关详情重复如下。
Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field.
在CMS签名数据内容类型中，消息摘要算法标识符位于SignedData digestAlgorithms字段和SignerInfo digestAlgorithm字段中。
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS Pub 180-3 [SHA2FIPS]. The algorithm identifiers for SHA-256 and SHA-384 are defined in [SHA2] and are repeated here:
SHA-256和SHA-384消息摘要算法在FIPS Pub 180-3[SHA2FIPS]中定义。SHA-256和SHA-384的算法标识符在[SHA2]中定义，并在此处重复：
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters. As specified in RFC 5754 [SHA2], implementations MUST generate SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters.
对于SHA-256和SHA-384，AlgorithmIdentifier参数字段是可选的，如果存在，参数字段必须包含空值。实现必须接受没有参数的SHA-256和SHA-384算法标识符。实现必须接受带有空参数的SHA-256和SHA-384算法标识符。如RFC 5754[SHA2]中所述，实现必须生成具有缺失参数的SHA-256和SHA-384算法标识符。
In Suite B, public key certificates used to verify S/MIME signatures MUST be compliant with the Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
在套件B中，用于验证S/MIME签名的公钥证书必须符合RFC 5759[SUITEBCERT]中指定的套件B证书配置文件。
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the Suite B digital signature algorithm. RFC 5753 [CMSECC] specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). Suite B compliant S/MIME implementations MUST follow the conventions in RFC 5753. Relevant details are repeated below.
椭圆曲线数字签名算法（ECDSA）是B组数字签名算法。RFC 5753[CMSECC]指定了将ECDSA与加密消息语法（CMS）一起使用的约定。与套件B兼容的S/MIME实现必须遵循RFC 5753中的约定。有关详情重复如下。
Within the CMS signed-data content type, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
在CMS签名数据内容类型中，签名算法标识符位于SignedData的SignerInfo signatureAlgorithm字段中。此外，签名算法标识符位于会签属性的SignerInfo signatureAlgorithm字段中。
RFC 5480 [PKI-ALG] defines the signature algorithm identifiers used in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. The identifiers are repeated here:
RFC 5480[PKI-ALG]定义了CMS中用于SHA-256 ECDSA和SHA-384 ECDSA的签名算法标识符。标识符在这里重复：
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
当使用ecdsa-with-SHA256或ecdsa-with-SHA384算法标识符时，必须缺少算法标识符参数字段。
When signing, the ECDSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480 [PKI-ALG]:
签名时，ECDSA算法生成两个值，通常称为r和s。要将这两个值作为一个签名传输，必须使用RFC 5480[PKI-ALG]中指定的ECDSA Sig值类型对其进行编码：
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords. In Suite B for S/MIME, ephemeral-static key agreement MUST be used as described in Section 4.1.
CMS包含以下通用密钥管理技术：密钥协议、密钥传输、以前分发的对称密钥加密密钥和密码。在S/MIME套件B中，必须按照第4.1节所述使用临时静态密钥协议。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. In Suite B for S/MIME, the Advanced Encryption Standard (AES) Key Wrap, as specified in RFC 3394 [SH] and [AESWRAP], MUST be used as the key-encryption algorithm. AES Key Wrap is discussed further in Section 4.2. The key-encryption key used with the AES Key Wrap algorithm is obtained from a key derivation function (KDF). In Suite B for S/MIME, there are two KDFs -- one based on SHA-256 and one based on SHA-384. These KDFs are discussed further in Section 4.3.
当使用密钥协商算法时，还需要密钥加密算法。在S/MIME套件B中，必须使用RFC 3394[SH]和[AESWRAP]中指定的高级加密标准（AES）密钥封装作为密钥加密算法。AES密钥封装将在第4.2节中进一步讨论。AES密钥包裹算法使用的密钥加密密钥是从密钥派生函数（KDF）获得的。在S/MIME的套件B中，有两个KDF——一个基于SHA-256，另一个基于SHA-384。第4.3节将进一步讨论这些KDF。
Elliptic Curve Diffie-Hellman (ECDH) is the Suite B key agreement algorithm.
椭圆曲线Diffie-Hellman（ECDH）是B组密钥协商算法。
S/MIME is used in store-and-forward communications, which means that ephemeral-static ECDH is always employed. This means that the message originator possesses an ephemeral ECDH key pair and that the message recipient possesses a static ECDH key pair whose public key is represented by an X.509 certificate. In Suite B, the certificate used to obtain the recipient's public key MUST be compliant with the Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
S/MIME用于存储和转发通信，这意味着始终使用短暂的静态ECDH。这意味着消息发起者拥有一个临时ECDH密钥对，而消息接收方拥有一个静态ECDH密钥对，其公钥由X.509证书表示。在套件B中，用于获取收件人公钥的证书必须符合RFC 5759[SUITEBCERT]中指定的套件B证书配置文件。
Section 3.1 of RFC 5753 [CMSECC] specifies the conventions for using ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
RFC 5753[CMSECC]第3.1节规定了将ECDH与CMS一起使用的约定。与Suite B兼容的S/MIME实现必须遵循这些约定。有关详情重复如下。
Within the CMS enveloped-data content type, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
在CMS信封数据内容类型中，密钥协议算法标识符位于信封数据接收方信息的KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中。
keyEncryptionAlgorithm MUST be one of the two algorithm identifiers listed below, and the algorithm identifier parameter field MUST be present and identify the key wrap algorithm. The key wrap algorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the ephemeral-static ECDH key agreement algorithm (see Section 4.3).
keyEncryptionAlgorithm必须是下面列出的两个算法标识符之一，并且算法标识符参数字段必须存在并标识密钥包裹算法。密钥包裹算法表示对称加密算法，用于使用临时静态ECDH密钥协商算法生成的成对密钥加密密钥加密内容加密密钥（见第4.3节）。
When implementing KE Set 1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2). When implementing KE Set 2, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes256-wrap.
实现KE Set 1时，keyEncryptionAlgorithm必须是dhSinglePass-stdDH-sha256kdf-scheme，keyEncryptionAlgorithm参数必须是包含id-aes128-wrap的KeyWrapAlgorithm（参见第4.2节）。在实现KE Set 2时，keyEncryptionAlgorithm必须是dhSinglePass-stdDH-sha384kdf-scheme，keyEncryptionAlgorithm参数必须是包含id-aes256-wrap的KeyWrapAlgorithm。
The algorithm identifiers for dhSinglePass-stdDH-sha256kdf-scheme and dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of [CMSECC], are:
[CMSECC]第7.1.4节中重复的dhSinglePass-stdDH-sha256kdf-scheme和dhSinglePass-stdDH-sha384kdf-scheme的算法标识符为：
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the type for their parameter:
这两个算法标识符都使用KeyWrapAlgorithm作为其参数的类型：
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm ::= AlgorithmIdentifier
The AES Key Wrap key-encryption algorithm, as specified in RFC 3394 [SH] and [AESWRAP], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. Section 8 of RFC 5753 [CMSECC] specifies the conventions for using AES Key Wrap with the pairwise key generated with ephemeral-static ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
RFC 3394[SH]和[AESWRAP]中规定的AES密钥包裹密钥加密算法用于使用使用临时静态ECDH生成的成对密钥加密密钥加密内容加密密钥。RFC 5753[CMSECC]的第8节规定了使用AES密钥包裹和CMS临时静态ECDH生成的成对密钥的约定。与Suite B兼容的S/MIME实现必须遵循这些约定。有关详情重复如下。
When implementing KE Set 1, the KeyWrapAlgorithm MUST be id-aes128-wrap. When implementing KE Set 2, the KeyWrapAlgorithm MUST be id-aes256-wrap.
在实现KE Set 1时，KeyWrapAlgorithm必须为id-aes128-wrap。在实现KE Set 2时，KeyWrapAlgorithm必须为id-aes256-wrap。
Within the CMS enveloped-data content type, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
在CMS信封数据内容类型中，密钥包裹算法标识符位于信封数据接收者信息KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中的KeyWrapAlgorithm参数中。
The algorithm identifiers for AES Key Wrap are specified in RFC 3394 [SH], and the ones needed for Suite B compliant S/MIME implementations are repeated here:
AES密钥封装的算法标识符在RFC 3394[SH]中指定，与套件B兼容的S/MIME实现所需的标识符在此处重复：
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2 of RFC 5753 [CMSECC] specify the conventions for using the KDF with the shared secret generated with ephemeral-static ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
基于SHA-256和SHA-384的KDF用于从短暂静态ECDH产生的共享密钥中导出成对密钥加密密钥。RFC 5753[CMSECC]第7.1.8节和第7.2节规定了使用KDF和CMS临时静态ECDH生成的共享秘密的约定。与Suite B兼容的S/MIME实现必须遵循这些约定。有关详情重复如下。
When implementing KE Set 1, the KDF based on SHA-256 MUST be used. When implementing KE Set 2, the KDF based on SHA-384 MUST be used.
在实现KE Set 1时，必须使用基于SHA-256的KDF。在实现KE Set 2时，必须使用基于SHA-384的KDF。
As specified in Section 7.2 of RFC 5753 [CMSECC], using ECDH with the CMS enveloped-data content type, the derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type, which is repeated here:
按照RFC 5753[CMSECC]第7.2节的规定，使用带有CMS封装数据内容类型的ECDH，密钥加密密钥的推导使用ECC CMS SharedInfo类型，此处重复：
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
In Suite B for S/MIME, the fields of ECC-CMS-SharedInfo are used as follows:
在S/MIME的套件B中，ECC CMS SharedInfo的字段使用如下：
keyInfo contains the object identifier of the key-encryption algorithm used to wrap the content-encryption key. In Suite B for S/MIME, if the AES-128 Key Wrap is used, then the keyInfo will contain id-aes128-wrap, and the parameters will be absent. In Suite B for S/MIME, if AES-256 Key Wrap is used, then the keyInfo will contain id-aes256-wrap, and the parameters will be absent.
keyInfo包含用于包装内容加密密钥的密钥加密算法的对象标识符。在S/MIME的套件B中，如果使用AES-128密钥包装，则keyInfo将包含id-aes128-Wrap，并且参数将不存在。在S/MIME的套件B中，如果使用AES-256密钥换行，则keyInfo将包含id-aes256-Wrap，并且参数将不存在。
entityUInfo optionally contains a random value provided by the message originator. If the user keying material (ukm) is present, then the entityUInfo MUST be present, and it MUST contain the ukm value. If the ukm is not present, then the entityUInfo MUST be absent.
entityUInfo可选地包含消息发起人提供的随机值。如果存在用户键控材质（ukm），则必须存在entityUInfo，并且必须包含ukm值。如果ukm不存在，则EntityUIInfo必须不存在。
suppPubInfo contains the length of the generated key-encryption key, in bits, represented as a 32-bit unsigned number, as described in RFC 2631 [CMSDH]. When a 128-bit AES key is used, the length MUST be 0x00000080. When a 256-bit AES key is used, the length MUST be 0x00000100.
suppPubInfo包含生成的密钥加密密钥的长度，以位为单位，表示为32位无符号数，如RFC 2631[CMSDH]中所述。使用128位AES密钥时，长度必须为0x00000080。使用256位AES密钥时，长度必须为0x00000100。
ECC-CMS-SharedInfo is DER encoded and used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [CMSDH]. Here, a counter value is not included in the keyInfo field because the KDF specified in [SEC1] ensures that sufficient keying data is provided.
ECC CMS SharedInfo按照[SEC1]第3.6.1节的规定进行顺序编码，并用作密钥推导功能的输入。请注意，ECC CMS SharedInfo与[CMSDH]中指定的其他信息不同。这里，keyInfo字段中不包括计数器值，因为[SEC1]中指定的KDF确保提供足够的键控数据。
The KDF specified in [SEC1] provides an algorithm for generating an essentially arbitrary amount of keying material (KM) from the shared secret produced by ephemeral-static ECDH, which is called Z for the remainder of this discussion. The KDF can be summarized as:
[SEC1]中指定的KDF提供了一种算法，用于从短暂静态ECDH产生的共享秘密生成基本上任意数量的密钥材料（KM），在本讨论的其余部分称为Z。KDF可概括为：
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
KM=散列（Z | |计数器| | ECC CMS SharedInfo）
To generate a key-encryption key (KEK), one or more KM blocks are generated, incrementing Counter appropriately, until enough material has been generated. The KM blocks are concatenated left to right:
要生成密钥加密密钥（KEK），将生成一个或多个KM块，并适当增加计数器，直到生成足够的材料。KM块从左到右连接：
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
KEK=KM（计数器=1）| | KM（计数器=2）。。。
The elements of the KDF are used as follows:
KDF的元素使用如下：
Hash is the one-way hash function. If KE Set 1 is used, the SHA-256 hash MUST be used. If KE Set 2 is used, the SHA-384 hash MUST be used.
哈希是单向哈希函数。如果使用KE Set 1，则必须使用SHA-256哈希。如果使用KE集合2，则必须使用SHA-384散列。
Z is the shared secret value generated by ephemeral-static ECDH. Leading zero bits MUST be preserved. In Suite B for S/MIME, if KE Set 1 is used, Z MUST be exactly 256 bits. In Suite B for S/MIME, if KE Set 2 is used, Z MUST be exactly 384 bits.
Z是短暂静态ECDH生成的共享秘密值。必须保留前导零位。在S/MIME的套件B中，如果使用KE Set 1，Z必须正好是256位。在S/MIME的套件B中，如果使用KE Set 2，Z必须正好是384位。
Counter is a 32-bit unsigned number, represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation. In Suite B for S/MIME, with both KE Set 1 and KE Set 2, exactly one iteration is needed; the Counter is not incremented.
计数器是一个32位无符号数，以网络字节顺序表示。对于任何密钥派生操作，其初始值必须为0x00000001。在S/MIME的套件B中，对于KE集1和KE集2，只需要一次迭代；计数器不会递增。
ECC-CMS-SharedInfo is composed as described above. It MUST be DER encoded.
ECC CMS SharedInfo的组成如上所述。它必须是DER编码的。
To generate a key-encryption key, one KM block is generated, with a Counter value of 0x00000001:
要生成密钥加密密钥，将生成一个KM块，计数器值为0x00000001：
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
In Suite B for S/MIME, when KE Set 1 is used, the key-encryption key MUST be the most significant 128 bits of the SHA-256 output value. In Suite B for S/MIME, when KE Set 2 is used, the key-encryption key MUST be the most significant 256 bits of the SHA-384 output value.
在S/MIME的套件B中，当使用KE Set 1时，密钥加密密钥必须是SHA-256输出值的最高有效128位。在S/MIME套件B中，当使用KE Set 2时，密钥加密密钥必须是SHA-384输出值的最高有效256位。
Note that the only source of secret entropy in this computation is Z. The effective key space of the key-encryption key is limited by the size of Z, in addition to any security level considerations imposed by the elliptic curve that is used. However, if entityUInfo is different for each message, a different key-encryption key will be generated for each message.
请注意，此计算中唯一的秘密熵来源是Z。除了所使用的椭圆曲线所施加的任何安全级别考虑之外，密钥加密密钥的有效密钥空间还受到Z大小的限制。但是，如果每条消息的entityUInfo不同，则会为每条消息生成不同的密钥加密密钥。
AES [AES] in Cipher Block Chaining (CBC) mode [MODES] is the Suite B for S/MIME content-encryption algorithm. RFC 3565 [CMSAES] specifies the conventions for using AES with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
密码块链接（CBC）模式中的AES[AES]模式[MODES]是S/MIME内容加密算法的套件B。RFC 3565[CMSAES]规定了在CMS中使用AES的约定。与Suite B兼容的S/MIME实现必须遵循这些约定。有关详情重复如下。
In Suite B for S/MIME, if KE Set 1 is used, AES-128 in CBC mode MUST be used for content encryption. In Suite B for S/MIME, if KE Set 2 is used, AES-256 in CBC mode MUST be used.
在S/MIME套件B中，如果使用KE Set 1，则CBC模式下的AES-128必须用于内容加密。在S/MIME的套件B中，如果使用KE Set 2，则必须使用CBC模式下的AES-256。
Within the CMS enveloped-data content type, content-encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field.
在CMS信封数据内容类型中，内容加密算法标识符位于EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm字段中。内容加密算法用于加密位于EnvelopedData EncryptedContentInfo encryptedContent字段中的内容。
The AES CBC content-encryption algorithm is described in [AES] and [MODES]. The algorithm identifier for AES-128 in CBC mode is:
AES CBC内容加密算法在[AES]和[MODES]中描述。CBC模式下AES-128的算法标识符为：
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
The algorithm identifier for AES-256 in CBC mode is:
CBC模式下AES-256的算法标识符为：
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:
AlgorithmIdentifier参数字段必须存在，并且参数字段必须包含AES-IV：
AES-IV ::= OCTET STRING (SIZE(16))
AES-IV ::= OCTET STRING (SIZE(16))
The 16-octet initialization vector is generated at random by the originator. See [RANDOM] for guidance on generation of random values.
发起者随机生成16个八位组的初始化向量。有关生成随机值的指导，请参见[随机]。
This document specifies the conventions for using the NSA's Suite B algorithms in S/MIME. All of the algorithms and algorithm identifiers have been specified in previous documents.
本文档规定了在s/MIME中使用NSA的Suite B算法的约定。所有算法和算法标识符已在以前的文档中指定。
Two minimum levels of security may be achieved using this specification. Users must consider their risk environment to determine which level is appropriate for their own use.
使用本规范可达到两个最低安全级别。用户必须考虑他们的风险环境来确定哪一个级别适合他们自己的使用。
See [RANDOM] for guidance on generation of random values.
有关生成随机值的指导，请参见[随机]。
The security considerations in RFC 5652 [CMS] discuss the CMS as a method for digitally signing data and encrypting data.
RFC 5652[CMS]中的安全注意事项讨论了CMS作为数字签名数据和加密数据的方法。
The security considerations in RFC 3370 [CMSALG] discuss cryptographic algorithm implementation concerns in the context of the CMS.
RFC 3370[CMSALG]中的安全注意事项讨论了CMS上下文中的密码算法实现问题。
The security considerations in RFC 5753 [CMSECC] discuss the use of elliptic curve cryptography (ECC) in the CMS.
RFC 5753[CMSECC]中的安全注意事项讨论了椭圆曲线加密（ECC）在CMS中的使用。
The security considerations in RFC 3565 [CMSAES] discuss the use of AES in the CMS.
RFC 3565[CMSAES]中的安全注意事项讨论了在CMS中使用AES。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月。
[AESWRAP] National Institute of Standards and Technology, "AES Key Wrap Specification", November 2001.
[AESWRAP]国家标准与技术研究所，“AES密钥封装规范”，2001年11月。
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
[DSS]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-3，2009年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMSDH]Rescorla，E.“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[CMSECC] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
[CMSECC]Turner，S.和D.Brown，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 5753，2010年1月。
[MODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS Pub 81, December 1980.
[模式]国家标准与技术研究所，“DES运行模式”，FIPS Pub 81，1980年12月。
[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[MSG]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[PKI-ALG]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", September 2000. <http://www.secg.org/collateral/sec1_final.pdf>.
[SEC1]高效密码标准组，“SEC1：椭圆曲线密码术”，2000年9月<http://www.secg.org/collateral/sec1_final.pdf>.
[SH] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SH]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[SHA2]Turner，S.，“将SHA2算法与加密消息语法结合使用”，RFC 5754，2010年1月。
[SHA2FIPS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.
[SH2FIPS]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS 180-32008年10月。
[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月。
[SUITEBCERT] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[SUITEBCERT]Solinas，J.和L.Zieglar，“套件B证书和证书撤销列表（CRL）配置文件”，RFC 5759，2010年1月。
[SUITEBSMIME] Housley, R. and J. Solinas, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", RFC 5008, September 2007.
[SuiteBSIME]Housley，R.和J.Solinas，“安全/多用途Internet邮件扩展（S/MIME）中的套件B”，RFC 5008，2007年9月。
[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
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[随机]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B Cryptography", January 2009. <http://www.nsa.gov/ia/programs/suiteb_cryptography>.
[NSA]美国国家安全局，“NSA套件B加密概况”，2009年1月<http://www.nsa.gov/ia/programs/suiteb_cryptography>.
Authors' Addresses
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Jerome A. Solinas National Information Assurance Laboratory National Security Agency 9800 Savage Road Fort George G. Meade, MD 20755 USA
美国马里兰州乔治堡G.米德萨维奇路9800号Jerome A.Solinas国家信息保障实验室国家安全局20755
EMail: jasolin@orion.ncsc.mil
EMail: jasolin@orion.ncsc.mil