Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8418 Vigil Security
Category: Standards Track August 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8418 Vigil Security
Category: Standards Track August 2018
ISSN: 2070-1721
Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
在加密消息语法（CMS）中使用带有X25519和X448的椭圆曲线Diffie-Hellman密钥协商算法
Abstract
摘要
This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).
本文档描述了在加密消息语法（CMS）中使用椭圆曲线Diffie-Hellman（ECDH）密钥协商算法与curve25519和curve448的约定。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8418.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8418.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. ASN.1 ......................................................3
2. Key Agreement ...................................................3
2.1. ANSI-X9.63-KDF .............................................4
2.2. HKDF .......................................................5
3. Enveloped-data Conventions ......................................5
3.1. EnvelopedData Fields .......................................6
3.2. KeyAgreeRecipientInfo Fields ...............................6
4. Authenticated-data Conventions ..................................7
4.1. AuthenticatedData Fields ...................................8
4.2. KeyAgreeRecipientInfo Fields ...............................8
5. Authenticated-enveloped-data Conventions ........................8
5.1. AuthEnvelopedData Fields ...................................8
5.2. KeyAgreeRecipientInfo Fields ...............................8
6. Certificate Conventions .........................................9
7. Key Agreement Algorithm Identifiers .............................9
8. SMIMECapabilities Attribute Conventions ........................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
Appendix A. ASN.1 Module ..........................................16
Acknowledgements ..................................................18
Author's Address ..................................................18
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. ASN.1 ......................................................3
2. Key Agreement ...................................................3
2.1. ANSI-X9.63-KDF .............................................4
2.2. HKDF .......................................................5
3. Enveloped-data Conventions ......................................5
3.1. EnvelopedData Fields .......................................6
3.2. KeyAgreeRecipientInfo Fields ...............................6
4. Authenticated-data Conventions ..................................7
4.1. AuthenticatedData Fields ...................................8
4.2. KeyAgreeRecipientInfo Fields ...............................8
5. Authenticated-enveloped-data Conventions ........................8
5.1. AuthEnvelopedData Fields ...................................8
5.2. KeyAgreeRecipientInfo Fields ...............................8
6. Certificate Conventions .........................................9
7. Key Agreement Algorithm Identifiers .............................9
8. SMIMECapabilities Attribute Conventions ........................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
Appendix A. ASN.1 Module ..........................................16
Acknowledgements ..................................................18
Author's Address ..................................................18
This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement using curve25519 and curve448 [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key agreement is supported in three CMS content types: the enveloped-data content type [CMS], authenticated-data content type [CMS], and the authenticated-enveloped-data content type [AUTHENV].
本文档描述了在加密消息语法（CMS）[CMS]中使用curve25519和curve448[CURVES]的椭圆曲线Diffie-Hellman（ECDH）密钥协议的约定。密钥协议支持三种CMS内容类型：信封数据内容类型[CMS]、认证数据内容类型[CMS]和认证信封数据内容类型[AUTHENV]。
The conventions for using some Elliptic Curve Cryptography (ECC) algorithms in CMS are described in [CMSECC]. These conventions cover the use of ECDH with some curves other than curve25519 and curve448 [CURVES]. Those other curves are not deprecated.
[CMSECC]中描述了在CMS中使用某些椭圆曲线密码（ECC）算法的约定。这些惯例涵盖了ECDH在曲线25519和曲线448[曲线]以外的一些曲线上的使用。这些其他曲线不是不推荐使用的。
Using curve25519 with Diffie-Hellman key agreement is referred to as "X25519". Using curve448 with Diffie-Hellman key agreement is referred to as "X448".
使用带有Diffie-Hellman密钥协议的curve25519称为“X25519”。使用带有Diffie-Hellman密钥协议的curve448称为“X448”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
CMS值是使用ASN.1[X680]生成的，它使用基本编码规则（BER）和可分辨编码规则（DER）[X690]。
In 1976, Diffie and Hellman described a means for two parties to agree upon a shared secret value in a manner that prevents eavesdroppers from learning the shared secret value [DH1976]. This secret may then be converted into pairwise symmetric keying material for use with other cryptographic algorithms. Over the years, many variants of this fundamental technique have been developed. This document describes the conventions for using Ephemeral-Static Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and X448 [CURVES].
1976年，Diffie和Hellman描述了一种方法，让双方以防止窃听者了解共享秘密价值的方式就共享秘密价值达成一致[DH1976]。然后，可以将该秘密转换为成对对称密钥材料，以便与其他加密算法一起使用。多年来，这项基本技术的许多变体已经开发出来。本文档描述了使用X25519和X448[曲线]的短暂静态椭圆曲线Diffie-Hellman（ECDH）密钥协议的约定。
The originator MUST use an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair MUST be used for a single CMS-protected content type, and then it MUST be discarded. The originator obtains the recipient's static public key from the recipient's certificate [PROFILE].
发起者必须使用在与接收者公钥相同的椭圆曲线上生成的临时公钥/私钥对。临时密钥对必须用于单个受CMS保护的内容类型，然后必须将其丢弃。发端人从收件人的证书[配置文件]中获取收件人的静态公钥。
X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. Conforming implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value, and abort if so, as described in Section 6 of [CURVES]. If an alternative implementation of these elliptic curves to that documented in Section 6 of [CURVES] is employed, then the additional checks specified in Section 7 of [CURVES] SHOULD be performed.
X25519在[曲线]第6.1节中描述，X448在[曲线]第6.2节中描述。一致性实现必须检查计算的Diffie-Hellman共享机密是否为全零值，如果是，则中止，如[曲线]第6节所述。如果采用[曲线]第6节中记录的椭圆曲线的替代方案，则应执行[曲线]第7节中规定的附加检查。
In [CURVES], the shared secret value that is produced by ECDH is called K. (In some other specifications, the shared secret value is called Z.) A Key Derivation Function (KDF) is used to produce a pairwise key-encryption key (KEK) from the shared secret value (K), the length of the KEK, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC].
在[曲线]中，ECDH产生的共享密钥值称为K（在一些其他规范中，共享密钥值称为Z）。密钥派生函数（KDF）用于根据共享密钥值（K）、KEK的长度和DER编码的ECC CMS SharedInfo结构[CMSECC]产生成对密钥加密密钥（KEK）。
The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for convenience.
为方便起见，此处重复[CMSECC]中的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 }
The ECC-CMS-SharedInfo keyInfo field contains the object identifier of the key-encryption algorithm and associated parameters. This algorithm will be used to wrap the content-encryption key. For example, the AES Key Wrap algorithm [AESKW] does not need parameters, so the algorithm identifier parameters are absent.
ECC CMS SharedInfo keyInfo字段包含密钥加密算法的对象标识符和相关参数。此算法将用于包装内容加密密钥。例如，AES密钥包裹算法[AESKW]不需要参数，因此没有算法标识符参数。
The ECC-CMS-SharedInfo entityUInfo field optionally contains additional keying material supplied by the sending agent. Note that [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm is placed in the entityUInfo field. By including the ukm, a different KEK is generated even when the originator ephemeral private key is improperly used more than once. Therefore, if the ukm field is present, it MUST be selected in a manner that provides, with very high probability, a unique value; however, there is no security benefit to using a ukm value that is longer than the KEK that will be produced by the KDF.
ECC CMS SharedInfo entityUInfo字段可选地包含发送代理提供的其他密钥资料。注意，[CMS]要求实现接受包含ukm字段的KeyAgreeRecipientInfo序列。如果存在ukm字段，则将ukm放置在entityUInfo字段中。通过包含ukm，即使发起人临时私钥被多次不当使用，也会生成不同的KEK。因此，如果存在ukm字段，则必须以提供非常高概率的唯一值的方式选择该字段；但是，使用比KDF生成的KEK长的ukm值不会带来安全好处。
The ECC-CMS-SharedInfo suppPubInfo field contains the length of the generated KEK, in bits, represented as a 32-bit number in network byte order. For example, the key length for AES-256 [AES] would be 0x00000100.
ECC CMS SharedInfo SUPPUBINFO字段包含生成的KEK的长度（以位为单位），表示为网络字节顺序的32位数字。例如，AES-256[AES]的密钥长度为0x00000100。
The ANSI-X9.63-KDF key derivation function is a simple construct based on a one-way hash function described in American National Standard X9.63 [X963]. This KDF is also described in Section 3.6.1 of [SEC1].
ANSI-X9.63-KDF密钥派生函数是基于美国国家标准X9.63[X963]中描述的单向散列函数的简单构造。[SEC1]的第3.6.1节也描述了该KDF。
Three values are concatenated to produce the input string to the KDF: 1. The shared secret value generated by ECDH, K. 2. The iteration counter, starting with one, as described below. 3. The DER-encoded ECC-CMS-SharedInfo structure.
连接三个值以生成KDF:1的输入字符串。ECDH生成的共享秘密值，K.2。迭代计数器，从一开始，如下所述。3.DER编码的ECC CMS SharedInfo结构。
To generate a key-encryption key (KEK), the KDF generates one or more keying material (KM) blocks, with the counter starting at 0x00000001, and incrementing the counter for each subsequent KM block until enough material has been generated. The 32-bit counter is
为了生成密钥加密密钥（KEK），KDF生成一个或多个密钥材料（KM）块，计数器从0x00000001开始，并增加每个后续KM块的计数器，直到生成足够的材料。32位计数器为
represented in network byte order. The KM blocks are concatenated left to right, and then the leftmost portion of the result is used as the pairwise key-encryption key, KEK:
以网络字节顺序表示。KM块从左到右连接，然后结果的最左侧部分用作成对密钥加密密钥KEK：
KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))
KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))
KEK = KM(counter=1) || KM(counter=2) ...
KEK=KM（计数器=1）| | KM（计数器=2）。。。
The Extract-and-Expand HMAC-based Key Derivation Function (HKDF) is a robust construct based on a one-way hash function described in RFC 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed by HKDF-Expand.
基于提取和扩展HMAC的密钥派生函数（HKDF）是基于RFC 5869[HKDF]中描述的单向散列函数的健壮构造。HKDF由两个步骤组成：HKDF提取，然后HKDF扩展。
Three values are used as inputs to the HKDF: 1. The shared secret value generated by ECDH, K. 2. The length in octets of the keying data to be generated. 3. The DER-encoded ECC-CMS-SharedInfo structure.
三个值用作HKDF的输入：1。ECDH生成的共享秘密值，K.2。要生成的键控数据的长度（以八位字节为单位）。3.DER编码的ECC CMS SharedInfo结构。
The ECC-CMS-SharedInfo structure optionally includes the ukm. If the ukm is present, the ukm is also used as the HKDF salt. HKDF uses an appropriate number of zero octets when no salt is provided.
ECC CMS SharedInfo结构可选地包括ukm。如果存在ukm，ukm也可用作HKDF盐。在不提供盐的情况下，HKDF使用适当数量的零八位字节。
The length of the generated KEK is used in two places, once in bits and once in octets. The ECC-CMS-SharedInfo structure includes the length of the generated KEK in bits. The HKDF-Expand function takes an argument for the length of the generated KEK in octets.
生成的KEK的长度在两个位置使用，一个在位中，一个在八位字节中。ECC CMS SharedInfo结构包括生成的KEK的长度（以位为单位）。HKDF Expand函数接受生成的KEK长度的参数（以八位字节为单位）。
In summary, to produce the pairwise key-encryption key, KEK:
总之，要生成成对密钥加密密钥KEK：
if ukm is provided, then salt = ukm, else salt is not provided PRK = HKDF-Extract(salt, K)
如果提供ukm，则盐=ukm，否则不提供盐PRK=HKDF提取物（盐，K）
KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))
KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))
The CMS enveloped-data content type [CMS] consists of an encrypted content and wrapped content-encryption keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the content-encryption key for that recipient. When there is more than one recipient, the same content-encryption key MUST be wrapped for each of them.
CMS信封数据内容类型[CMS]由一个或多个收件人的加密内容和包装内容加密密钥组成。ECDH密钥协商算法用于在发起者和特定接收者之间生成成对的KEK。然后，KEK用于包装该收件人的内容加密密钥。当有多个收件人时，必须为每个收件人包装相同的内容加密密钥。
A compliant implementation MUST meet the requirements for constructing an enveloped-data content type in Section 6 of [CMS].
合规实现必须满足[CMS]第6节中构建封装数据内容类型的要求。
A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. The content-encryption key is used to encrypt the content.
必须为封装数据内容类型的每个实例随机生成内容加密密钥。内容加密密钥用于加密内容。
The enveloped-data content type is ASN.1 encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be populated as described in Section 6 of [CMS]. The RecipientInfo choice is described in Section 6.2 of [CMS], and repeated here for convenience.
封装的数据内容类型是使用EnvelopedData语法进行ASN.1编码的。必须按照[CMS]第6节的说明填充EnvelopedData语法字段。[CMS]第6.2节描述了RecipientInfo选项，为方便起见，在此重复。
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
For the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
对于使用X25519或X448的收件人，必须使用RecipientInfo-kari选项。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in this section when X25519 or X448 is employed for one or more recipients.
当一个或多个收件人使用X25519或X448时，必须按照本节所述填充KeyAgreeRecipientInfo语法的字段。
The KeyAgreeRecipientInfo version MUST be 3.
KeyAgreentRecipientInfo版本必须为3。
The KeyAgreeRecipientInfo originator provides three alternatives for identifying the originator's public key, and the originatorKey alternative MUST be used. The originatorKey MUST contain an ephemeral key for the originator. The originatorKey algorithm field MUST contain the id-X25519 or the id-X448 object identifier. The originator's ephemeral public key MUST be encoded as an OCTET STRING.
KeyAgreentRecipientInfo发起人提供了三种备选方案来识别发起人的公钥，必须使用OriginateWorkey备选方案。发起人必须包含发起人的临时密钥。原始工作算法字段必须包含id-X25519或id-X448对象标识符。发起者的临时公钥必须编码为八位字节字符串。
The object identifiers for X25519 and X448 have been assigned in [RFC8410]. They are repeated below for convenience.
X25519和X448的对象标识符已在[RFC8410]中分配。为了方便起见，下面重复这些步骤。
When using X25519, the public key contains exactly 32 octets, and the id-X25519 object identifier is used:
使用X25519时，公钥正好包含32个八位字节，并且使用id-X25519对象标识符：
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
When using X448, the public key contains exactly 56 octets, and the id-X448 object identifier is used:
使用X448时，公钥正好包含56个八位字节，并且使用id-X448对象标识符：
id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
KeyAgreeRecipientInfo ukm is optional. The processing of the ukm with the ANSI-X9.63-KDF key derivation function is described in Section 2.1, and the processing of the ukm with the HKDF key derivation function is described in Section 2.2.
KeyAgreeRecipientInfo ukm是可选的。第2.1节描述了使用ANSI-X9.63-KDF密钥派生函数处理ukm，第2.2节描述了使用HKDF密钥派生函数处理ukm。
The KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm that will be used to wrap the content-encryption key. The conventions for using AES-128, AES-192, and AES-256 in the key wrap mode are specified in [CMSAES].
KeyAgreentRecipientInfo keyEncryptionAlgorithm必须包含将用于包装内容加密密钥的密钥加密算法的对象标识符。[CMSAES]中规定了在密钥换行模式下使用AES-128、AES-192和AES-256的约定。
The KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient identifier and encrypted key for one or more recipients. 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 X25519 or X448 public key. The RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
KeyAgreentRecipientInfo recipientEncryptedKeys包括收件人标识符和一个或多个收件人的加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态X25519或X448公钥。RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgorithm指定的算法使用成对密钥加密密钥加密的内容加密密钥。
The CMS authenticated-data content type [CMS] consists of an authenticated content, a message authentication code (MAC), and encrypted authentication keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the authentication key for that recipient. When there is more than one recipient, the same authentication key MUST be wrapped for each of them.
CMS认证数据内容类型[CMS]由认证内容、消息认证码（MAC）和一个或多个收件人的加密认证密钥组成。ECDH密钥协商算法用于在发起者和特定接收者之间生成成对的KEK。然后，KEK用于包装该收件人的身份验证密钥。当有多个收件人时，必须为每个收件人包装相同的身份验证密钥。
A compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 9 of [CMS].
符合要求的实现必须满足[CMS]第9节中构造认证数据内容类型的要求。
An authentication key MUST be randomly generated for each instance of an authenticated-data content type. The authentication key is used to compute the MAC over the content.
必须为经过身份验证的数据内容类型的每个实例随机生成身份验证密钥。身份验证密钥用于计算内容上的MAC。
The authenticated-data content type is ASN.1 encoded using the AuthenticatedData syntax. The fields of the AuthenticatedData syntax MUST be populated as described in [CMS]; for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
已验证的数据内容类型是使用AuthenticatedData语法进行ASN.1编码的。必须按照[CMS]中的说明填充AuthenticatedData语法的字段；对于使用X25519或X448的收件人，必须使用RecipientInfo-kari选项。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document.
KeyAgreeRecipientInfo语法的字段必须按照本文档第3.2节所述进行填充。
The CMS authenticated-enveloped-data content type [AUTHENV] consists of an authenticated and encrypted content and encrypted content-authenticated-encryption keys for one or more recipients. The ECDH key agreement algorithm is used to generate a pairwise KEK between the originator and a particular recipient. Then, the KEK is used to wrap the content-authenticated-encryption key for that recipient. When there is more than one recipient, the same content-authenticated-encryption key MUST be wrapped for each of them.
CMS认证信封数据内容类型[AUTHENV]由认证和加密内容以及一个或多个收件人的加密内容认证加密密钥组成。ECDH密钥协商算法用于在发起者和特定接收者之间生成成对的KEK。然后，KEK用于包装该收件人的内容认证加密密钥。当有多个收件人时，必须为每个收件人包装相同的内容验证加密密钥。
A compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 2 of [AUTHENV].
符合要求的实现必须满足[AUTHENV]第2节中构造经过身份验证的数据内容类型的要求。
A content-authenticated-encryption key MUST be randomly generated for each instance of an authenticated-enveloped-data content type. The content-authenticated-encryption key is used to authenticate and encrypt the content.
必须为经过身份验证的信封数据内容类型的每个实例随机生成经过内容身份验证的加密密钥。内容认证加密密钥用于对内容进行认证和加密。
The authenticated-enveloped-data content type is ASN.1 encoded using the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData syntax MUST be populated as described in [AUTHENV]; for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used.
经过身份验证的信封数据内容类型是使用AuthEnvelopedData语法进行ASN.1编码的。AuthEnvelopedData语法的字段必须按照[AUTHENV]中的说明填充；对于使用X25519或X448的收件人，必须使用RecipientInfo-kari选项。
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document.
KeyAgreeRecipientInfo语法的字段必须按照本文档第3.2节所述进行填充。
RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. A recipient static public key is needed for X25519 or X448, and the originator obtains that public key from the recipient's certificate. The conventions for carrying X25519 and X448 public keys are specified in [RFC8410].
RFC 5280[PROFILE]指定在Internet应用程序中使用X.509证书的配置文件。X25519或X448需要收件人静态公钥，并且发起者从收件人的证书中获得该公钥。[RFC8410]中规定了携带X25519和X448公钥的约定。
The following object identifiers are assigned in [CMSECC] to indicate ECDH with ANSI-X9.63-KDF using various one-way hash functions. These are expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm. These are repeated here for convenience.
[CMSECC]中分配了以下对象标识符，以使用各种单向散列函数指示具有ANSI-X9.63-KDF的ECDH。这些将被用作算法标识符，其参数指定密钥加密算法。为了方便起见，这里重复这些。
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
The following object identifiers are assigned to indicate ECDH with HKDF using various one-way hash functions. These are expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm.
分配以下对象标识符，以使用各种单向散列函数通过HKDF指示ECDH。这些将被用作算法标识符，其参数指定密钥加密算法。
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
A sending agent MAY announce to other agents that it supports ECDH key agreement using the SMIMECapabilities signed attribute in a signed message [SMIME] or a certificate [CERTCAP]. Following the pattern established in [CMSECC], the SMIMECapabilities associated with ECDH carries a DER-encoded object identifier that identifies support for ECDH in conjunction with a particular KDF, and it includes a parameter that names the key wrap algorithm.
发送代理可以在签名消息[SMIME]或证书[CERTCAP]中使用SMIMECapabilities signed属性向其他代理宣布它支持ECDH密钥协议。按照[CMSECC]中建立的模式，与ECDH相关联的SMIMECapabilities携带一个DER编码的对象标识符，该标识符与特定KDF一起标识对ECDH的支持，并包括一个命名密钥包裹算法的参数。
The following SMIMECapabilities values (in hexadecimal) from [CMSECC] might be of interest to implementations that support X25519 and X448:
支持X25519和X448的实现可能会对[CMSECC]中的以下SMIMECapabilities值（十六进制）感兴趣：
ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 05
使用ANSI-X9.63-KDF和SHA-256的ECDH；使用AES-128密钥包：30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 05
采用ANSI-X9.63-KDF和SHA-384的ECDH；使用AES-128密钥包：30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 05
使用ANSI-X9.63-KDF和SHA-512的ECDH；使用AES-128密钥包：30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 2D
使用ANSI-X9.63-KDF和SHA-256的ECDH；使用AES-256密钥包：30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 2D
采用ANSI-X9.63-KDF和SHA-384的ECDH；使用AES-256密钥包：30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 2D
使用ANSI-X9.63-KDF和SHA-512的ECDH；使用AES-256密钥包：30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 2D
The following SMIMECapabilities values (in hexadecimal) based on the algorithm identifiers in Section 7 of this document might be of interest to implementations that support X25519 and X448:
以下基于本文档第7节中的算法标识符的SMIMECapabilities值（十六进制）可能会引起支持X25519和X448的实现的兴趣：
ECDH with HKDF using SHA-256; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH与香港国防军使用SHA-256；使用AES-128密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-384; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH与香港国防军使用SHA-384；使用AES-128密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-512; uses AES-128 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH与香港国防军使用SHA-512；使用AES-128密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 05
ECDH with HKDF using SHA-256; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH与香港国防军使用SHA-256；使用AES-256密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with HKDF using SHA-384; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH与香港国防军使用SHA-384；使用AES-256密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH with HKDF using SHA-512; uses AES-256 key wrap: 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 2D
ECDH与香港国防军使用SHA-512；使用AES-256密钥包：30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 48 01 65 03 04 01 2D
Please consult the security considerations of [CMS] for security considerations related to the enveloped-data content type and the authenticated-data content type.
请参考[CMS]的安全注意事项，了解与封装数据内容类型和已验证数据内容类型相关的安全注意事项。
Please consult the security considerations of [AUTHENV] for security considerations related to the authenticated-enveloped-data content type.
请参阅[AUTHENV]的安全注意事项，以了解与已验证的信封数据内容类型相关的安全注意事项。
Please consult the security considerations of [CURVES] for security considerations related to the use of X25519 and X448.
有关使用X25519和X448的安全注意事项，请参考[CURVES]的安全注意事项。
The originator uses an ephemeral public/private key pair that is generated on the same elliptic curve as the public key of the recipient. The ephemeral key pair is used for a single CMS protected content type, and then it is discarded. If the originator wants to be able to decrypt the content (for enveloped-data and authenticated-enveloped-data) or check the authentication (for authenticated-data), then the originator needs to treat themselves as a recipient.
发起者使用在与接收者公钥相同的椭圆曲线上生成的临时公钥/私钥对。临时密钥对用于单个CMS保护的内容类型，然后将其丢弃。如果发端人希望能够解密内容（对于封装数据和经过身份验证的封装数据）或检查身份验证（对于经过身份验证的数据），则发端人需要将自己视为收件人。
As specified in [CMS], implementations MUST support processing of the KeyAgreeRecipientInfo ukm field; this ensures that interoperability is not a concern whether the ukm is present or absent. The ukm is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. When present, the ukm ensures that a different key-encryption key is generated, even when the originator ephemeral private key is improperly used more than once.
如[CMS]所述，实现必须支持KeyAgreeRecipientInfo ukm字段的处理；这确保了互操作性不受ukm存在与否的影响。ukm位于ECC CMS SharedInfo结构的EntityUIInfo字段中。当存在时，ukm确保生成不同的密钥加密密钥，即使发起人临时私钥被多次不当使用。
One object identifier for the ASN.1 module in Appendix A was assigned in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)" registry on [IANA-SMI]:
附录A中ASN.1模块的一个对象标识符在[IANA-SMI]上的“S/MIME模块标识符的SMI安全性（1.2.840.113549.1.9.16.0）”注册表中分配：
id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) 67 }
id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) 67 }
Three object identifiers for the Key Agreement Algorithm Identifiers in Section 7 were assigned in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry on [IANA-SMI]:
在[IANA-SMI]上的“S/MIME算法的SMI安全性（1.2.840.113549.1.9.16.3）”注册表中为第7节中的密钥协议算法标识符分配了三个对象标识符：
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <https://www.rfc-editor.org/info/rfc5083>.
[AUTHENV]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，DOI 10.17487/RFC5083，2007年11月<https://www.rfc-editor.org/info/rfc5083>.
[CERTCAP] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, <https://www.rfc-editor.org/info/rfc4262>.
[CERTCAP]Santesson，S.，“用于安全/多用途Internet邮件扩展（S/MIME）功能的X.509证书扩展”，RFC 4262，DOI 10.17487/RFC4262，2005年12月<https://www.rfc-editor.org/info/rfc4262>.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <https://www.rfc-editor.org/info/rfc5911>.
[CMSASN1]Hoffman，P.和J.Schaad，“用于加密消息语法（CMS）和S/MIME的新ASN.1模块”，RFC 5911，DOI 10.17487/RFC5911，2010年6月<https://www.rfc-editor.org/info/rfc5911>.
[CMSECC] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[CMSECC]Turner，S.和D.Brown，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 5753，DOI 10.17487/RFC5753，2010年1月<https://www.rfc-editor.org/info/rfc5753>.
[CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[CURVES]Langley，A.，Hamburg，M.和S.Turner，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<https://www.rfc-editor.org/info/rfc7748>.
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[HKDF]Krawczyk，H.和P.Erenen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<https://www.rfc-editor.org/info/rfc5869>.
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[PROFILE]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8410] Josefsson, S., and J. Schaad, "Algorithm Identifiers for Ed25519,Ed448, Ed448ph, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8410]Josefsson，S.和J.Schaad，“用于互联网X.509公钥基础设施的Ed25519、Ed448、Ed448ph、X25519和X448的算法标识符”，RFC 8410，DOI 10.17487/RFC8410，2018年8月<https://www.rfc-editor.org/info/rfc8410>.
[SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic Curve Cryptography", Cericom Research, version 2.0, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1]高效密码标准，“第1节：椭圆曲线密码术”，Cericom Research，版本2.0，2009年5月<http://www.secg.org/sec1-v2.pdf>.
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[SMIME]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<https://www.rfc-editor.org/info/rfc5751>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.
[X680]ITU-T，“信息技术——抽象语法符号一（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC 8824-12015年8月<https://www.itu.int/rec/T-REC-X.680/en>.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[X690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/en>.
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月。
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[AESKW]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，DOI 10.17487/RFC3394，2002年9月<https://www.rfc-editor.org/info/rfc3394>.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.
[CMSAES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，DOI 10.17487/RFC3565，2003年7月<https://www.rfc-editor.org/info/rfc3565>.
[DH1976] Diffie, W., and M. E. Hellman, "New Directions in Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, November 1976, pp. 644-654.
[DH1976]Diffie，W.和M.E.Hellman，“密码学的新方向”，IEEE Trans。关于信息。《理论》，第IT-22卷，1976年11月，第644-654页。
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <https://www.iana.org/assignments/smi-numbers>.
[IANA-SMI]IANA，“管理信息（SMI）编号结构（MIB模块注册）”<https://www.iana.org/assignments/smi-numbers>.
[X963] American National Standards Institute, "Public-Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", American National Standard X9.63-2001, November 2001.
[X963]美国国家标准协会，“金融服务业的公钥加密：使用椭圆曲线加密的密钥协议和密钥传输”，美国国家标准X9.63-2001，2001年11月。
CMSECDHAlgs-2017
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecdh-alg-2017(67) }
CMSECDHAlgs-2017
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecdh-alg-2017(67) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
--全部出口
IMPORTS
进口
KeyWrapAlgorithm
FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
KeyWrapAlgorithm
FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
KEY-AGREE, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
KEY-AGREE, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
dhSinglePass-stdDH-sha256kdf-scheme,
dhSinglePass-stdDH-sha384kdf-scheme,
dhSinglePass-stdDH-sha512kdf-scheme,
kaa-dhSinglePass-stdDH-sha256kdf-scheme,
kaa-dhSinglePass-stdDH-sha384kdf-scheme,
kaa-dhSinglePass-stdDH-sha512kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
FROM CMSECCAlgs-2009-02 -- in [CMSECC]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-cms-ecc-alg-2009-02(46) }
;
dhSinglePass-stdDH-sha256kdf-scheme,
dhSinglePass-stdDH-sha384kdf-scheme,
dhSinglePass-stdDH-sha512kdf-scheme,
kaa-dhSinglePass-stdDH-sha256kdf-scheme,
kaa-dhSinglePass-stdDH-sha384kdf-scheme,
kaa-dhSinglePass-stdDH-sha512kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
FROM CMSECCAlgs-2009-02 -- in [CMSECC]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-cms-ecc-alg-2009-02(46) }
;
-- -- Object Identifiers --
----对象标识符--
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg 19 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg 20 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg 21 }
-- -- Extend the Key Agreement Algorithms in [CMSECC] --
----扩展[CMSECC]中的密钥协商算法--
KeyAgreementAlgs KEY-AGREE ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
KeyAgreementAlgs KEY-AGREE ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
-- -- Extend the S/MIME CAPS in [CMSECC] --
----扩展[CMSECC]中的S/MIME上限--
SMimeCAPS SMIME-CAPS ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps }
SMimeCAPS SMIME-CAPS ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps }
cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme }
cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme }
cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
END
终止
Acknowledgements
致谢
Many thanks to Roni Even, Daniel Migault, Eric Rescorla, Jim Schaad, Stefan Santesson, and Sean Turner for their review and insightful suggestions.
感谢Roni、Daniel Migault、Eric Rescorla、Jim Schaad、Stefan Santesson和Sean Turner的评论和富有洞察力的建议。
Author's Address
作者地址
Russ Housley 918 Spring Knoll Drive Herndon, VA 20170 United States of America
美国弗吉尼亚州赫恩登市罗斯霍斯利918斯普林诺尔大道，邮编：20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com