Network Working Group S. Blake-Wilson
Request for Comments: 3278 D. Brown
Category: Informational Certicom Corp
P. Lambert
Cosine Communications
April 2002
Network Working Group S. Blake-Wilson
Request for Comments: 3278 D. Brown
Category: Informational Certicom Corp
P. Lambert
Cosine Communications
April 2002
Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
椭圆曲线密码（ECC）算法在加密消息语法（CMS）中的应用
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
本文档介绍如何在加密消息语法（CMS）中使用椭圆曲线加密（ECC）公钥算法。ECC算法支持创建数字签名和交换密钥以加密或验证内容。算法处理的定义基于ANSI X9.62标准，该标准由ANSI X9F1工作组、IEEE 1363标准和SEC 1标准制定。
The readers attention is called to the Intellectual Property Rights section at the end of this document.
读者请注意本文件末尾的知识产权部分。
Table of Contents
目录
1 Introduction ................................................... 2
1.1 Requirements terminology .................................. 3
2 SignedData using ECC .......................................... 3
2.1 SignedData using ECDSA ................................... 3
2.1.1 Fields of the SignedData .......................... 3
2.1.2 Actions of the sending agent ...................... 4
2.1.3 Actions of the receiving agent .................... 4
3 EnvelopedData using ECC ....................................... 4
3.1 EnvelopedData using ECDH ................................. 5
3.1.1 Fields of KeyAgreeRecipientInfo ................... 5
3.1.2 Actions of the sending agent ...................... 5
3.1.3 Actions of the receiving agent .................... 6
3.2 EnvelopedData using 1-Pass ECMQV ......................... 6
3.2.1 Fields of KeyAgreeRecipientInfo ................... 6
3.2.2 Actions of the sending agent ...................... 7
3.2.3 Actions of the receiving agent .................... 7
4 AuthenticatedData using ECC ............ ...................... 8
4.1 AuthenticatedData using 1-pass ECMQV ..................... 8
4.1.1 Fields of KeyAgreeRecipientInfo ................... 8
4.1.2 Actions of the sending agent ...................... 8
4.1.3 Actions of the receiving agent .................... 8
5 Recommended Algorithms and Elliptic Curves .................... 9
6 Certificates using ECC ........................................ 9
7 SMIMECapabilities Attribute and ECC ........................... 9
8 ASN.1 Syntax .................................................. 10
8.1 Algorithm identifiers .................................... 10
8.2 Other syntax ............................................. 11
9 Summary ....................................................... 12
References ....................................................... 13
Security Considerations .......................................... 14
Intellectual Property Rights ..................................... 14
Acknowledgments .................................................. 15
Authors' Addresses ............................................... 15
Full Copyright Statement ......................................... 16
1 Introduction ................................................... 2
1.1 Requirements terminology .................................. 3
2 SignedData using ECC .......................................... 3
2.1 SignedData using ECDSA ................................... 3
2.1.1 Fields of the SignedData .......................... 3
2.1.2 Actions of the sending agent ...................... 4
2.1.3 Actions of the receiving agent .................... 4
3 EnvelopedData using ECC ....................................... 4
3.1 EnvelopedData using ECDH ................................. 5
3.1.1 Fields of KeyAgreeRecipientInfo ................... 5
3.1.2 Actions of the sending agent ...................... 5
3.1.3 Actions of the receiving agent .................... 6
3.2 EnvelopedData using 1-Pass ECMQV ......................... 6
3.2.1 Fields of KeyAgreeRecipientInfo ................... 6
3.2.2 Actions of the sending agent ...................... 7
3.2.3 Actions of the receiving agent .................... 7
4 AuthenticatedData using ECC ............ ...................... 8
4.1 AuthenticatedData using 1-pass ECMQV ..................... 8
4.1.1 Fields of KeyAgreeRecipientInfo ................... 8
4.1.2 Actions of the sending agent ...................... 8
4.1.3 Actions of the receiving agent .................... 8
5 Recommended Algorithms and Elliptic Curves .................... 9
6 Certificates using ECC ........................................ 9
7 SMIMECapabilities Attribute and ECC ........................... 9
8 ASN.1 Syntax .................................................. 10
8.1 Algorithm identifiers .................................... 10
8.2 Other syntax ............................................. 11
9 Summary ....................................................... 12
References ....................................................... 13
Security Considerations .......................................... 14
Intellectual Property Rights ..................................... 14
Acknowledgments .................................................. 15
Authors' Addresses ............................................... 15
Full Copyright Statement ......................................... 16
1 Introduction
1导言
The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent. This specification defines a profile for the use of Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. The ECC algorithms are incorporated into the following CMS content types:
加密消息语法（CMS）与加密算法无关。本规范定义了在CMS中使用椭圆曲线加密（ECC）公钥算法的配置文件。ECC算法包含在以下CMS内容类型中：
- 'SignedData' to support ECC-based digital signature methods (ECDSA) to sign content
- “SignedData”支持基于ECC的数字签名方法（ECDSA）对内容进行签名
- 'EnvelopedData' to support ECC-based public-key agreement methods (ECDH and ECMQV) to generate pairwise key-encryption keys to encrypt content-encryption keys used for content encryption
- “EnvelopedData”支持基于ECC的公钥协议方法（ECDH和ECMQV），以生成成对密钥加密密钥，对用于内容加密的内容加密密钥进行加密
- 'AuthenticatedData' to support ECC-based public-key agreement methods (ECMQV) to generate pairwise key-encryption keys to encrypt MAC keys used for content authentication and integrity
- “AuthenticatedData”支持基于ECC的公钥协议方法（ECMQV），以生成成对密钥加密密钥，对用于内容认证和完整性的MAC密钥进行加密
Certification of EC public keys is also described to provide public-key distribution in support of the specified techniques.
还描述了EC公钥的认证，以提供公钥分发以支持指定的技术。
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 [MUST].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[必须]中的说明进行解释。
2 SignedData using ECC
2使用ECC的已签名数据
This section describes how to use ECC algorithms with the CMS SignedData format to sign data.
本节介绍如何使用CMS SignedData格式的ECC算法对数据进行签名。
This section describes how to use the Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in [X9.62]. The method is the elliptic curve analog of the Digital Signature Algorithm (DSA) [FIPS 186-2].
本节介绍如何对SignedData使用椭圆曲线数字签名算法（ECDSA）。[X9.62]中规定了ECDSA。该方法是数字签名算法（DSA）的椭圆曲线模拟[FIPS 186-2]。
In an implementation that uses ECDSA with CMS SignedData, the following techniques and formats MUST be used.
在使用ECDSA和CMS SignedData的实现中，必须使用以下技术和格式。
When using ECDSA with SignedData, the fields of SignerInfo are as in [CMS], but with the following restrictions:
将ECDSA与SignedData一起使用时，SignerInfo的字段与[CMS]中的字段相同，但有以下限制：
digestAlgorithm MUST contain the algorithm identifier sha-1 (see Section 8.1) which identifies the SHA-1 hash algorithm.
digestAlgorithm必须包含识别sha-1哈希算法的算法标识符sha-1（见第8.1节）。
signatureAlgorithm contains the algorithm identifier ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA signature algorithm.
signatureAlgorithm包含识别ecdsa签名算法的算法标识符ecdsa-with-SHA1（参见第8.1节）。
signature MUST contain the DER encoding (as an octet string) of a value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2).
签名必须包含ASN.1类型ECDSA Sig值的DER编码（作为八位字节字符串）（参见第8.2节）。
When using ECDSA, the SignedData certificates field MAY include the certificate(s) for the EC public key(s) used in the generation of the ECDSA signatures in SignedData. ECC certificates are discussed in Section 6.
使用ECDSA时，SignedData certificates字段可能包括用于生成SignedData中ECDSA签名的EC公钥的证书。第6节讨论了ECC证书。
When using ECDSA with SignedData, the sending agent uses the message digest calculation process and signature generation process for SignedData that are specified in [CMS]. To sign data, the sending agent uses the signature method specified in [X9.62, Section 5.3] with the following exceptions:
将ECDSA与SignedData一起使用时，发送代理使用[CMS]中指定的消息摘要计算过程和SignedData的签名生成过程。为了对数据进行签名，发送代理使用[X9.62，第5.3节]中规定的签名方法，但以下情况除外：
- In [X9.62, Section 5.3.1], the integer "e" is instead determined by converting the message digest generated according to [CMS, Section 5.4] to an integer using the data conversion method in [X9.62, Section 4.3.2].
- 在[X9.62，第5.3.1节]中，整数“e”是通过使用[X9.62，第4.3.2节]中的数据转换方法将根据[CMS，第5.4节]生成的消息摘要转换为整数来确定的。
The sending agent encodes the resulting signature using the ECDSA-Sig-Value syntax (see Section 8.2) and places it in the SignerInfo signature field.
发送代理使用ECDSA Sig Value语法（参见第8.2节）对生成的签名进行编码，并将其放置在SignerInfo签名字段中。
When using ECDSA with SignedData, the receiving agent uses the message digest calculation process and signature verification process for SignedData that are specified in [CMS]. To verify SignedData, the receiving agent uses the signature verification method specified in [X9.62, Section 5.4] with the following exceptions:
将ECDSA与SignedData一起使用时，接收代理使用[CMS]中指定的SignedData的消息摘要计算过程和签名验证过程。为验证签名数据，接收代理使用[X9.62，第5.4节]中规定的签名验证方法，但以下情况除外：
- In [X9.62, Section 5.4.1] the integer "e'" is instead determined by converting the message digest generated according to [CMS, Section 5.4] to an integer using the data conversion method in [X9.62, Section 4.3.2].
- 在[X9.62，第5.4.1节]中，整数“e”是通过使用[X9.62，第4.3.2节]中的数据转换方法将根据[CMS，第5.4节]生成的消息摘要转换为整数来确定的。
In order to verify the signature, the receiving agent retrieves the integers r and s from the SignerInfo signature field of the received message.
为了验证签名，接收代理从接收到的消息的SignerInfo签名字段中检索整数r和s。
3 EnvelopedData using ECC Algorithms
使用ECC算法的3信封数据
This section describes how to use ECC algorithms with the CMS EnvelopedData format.
本节介绍如何将ECC算法与CMS EnvelopedData格式结合使用。
This section describes how to use the ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363]. Ephemeral-static ECDH is the the elliptic curve analog of the ephemeral-static Diffie-Hellman key agreement algorithm specified jointly in the documents [CMS, Section 12.3.1.1] and [CMS-DH].
本节描述了如何将临时静态椭圆曲线Diffie-Hellman（ECDH）密钥协商算法与EnvelopedData结合使用。[SEC1]和[IEEE1363]中规定了瞬时静态ECDH。临时静态ECDH是文件[CMS，第12.3.1.1节]和[CMS-DH]中联合规定的临时静态Diffie-Hellman密钥协商算法的椭圆曲线模拟。
In an implementation that uses ECDH with CMS EnvelopedData with key agreement, the following techniques and formats MUST be used.
在使用ECDH和CMS EnvelopedData以及密钥协议的实现中，必须使用以下技术和格式。
When using ephemeral-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo are as in [CMS], but with the following restrictions:
当对EnvelopedData使用临时静态ECDH时，KeyAgreeRecipientInfo字段与[CMS]中的字段相同，但有以下限制：
originator MUST be the alternative originatorKey. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 8.1) with NULL parameters. The originatorKey publicKey field MUST contain the DER-encoding of a value of the ASN.1 type ECPoint (see Section 8.2), which represents the sending agent's ephemeral EC public key.
发起人必须是备选发起人。OriginateWorkey算法字段必须包含id ecPublicKey对象标识符（见第8.1节），且参数为空。OriginateWorkey公钥字段必须包含ASN.1类型ECPoint值的DER编码（参见第8.2节），该值表示发送代理的临时EC公钥。
keyEncryptionAlgorithm MUST contain the dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section 8.1) if standard ECDH primitive is used, or the dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see Section 8.1) if the cofactor ECDH primitive is used. The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm identifier that indicates the symmetric encryption algorithm used to encrypt the content-encryption key (CEK) with the key-encryption key (KEK).
如果使用标准ECDH原语，则keyEncryptionAlgorithm必须包含dhSinglePass-stdDH-sha1kdf-scheme对象标识符（参见第8.1节）；如果使用辅因子ECDH原语，则必须包含dhSinglePass-cofactorDH-sha1kdf-scheme对象标识符（参见第8.1节）。参数字段包含KeyWrapAlgorithm。KeyWrapAlgorithm是算法标识符，指示用于使用密钥加密密钥（KEK）加密内容加密密钥（CEK）的对称加密算法。
When using ephemeral-static ECDH with EnvelopedData, the sending agent first obtains the recipient's EC public key and domain parameters (e.g. from the recipient's certificate). The sending agent then determines an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key-size in bits, and also a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending agent then performs the key deployment and the key agreement operation of the Elliptic Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As a result the sending agent obtains:
当使用带有EnvelopedData的临时静态ECDH时，发送代理首先获取收件人的EC公钥和域参数（例如，从收件人的证书）。然后，发送代理确定一个整数“keydatalen”，它是以位为单位的KeyWrapAlgorithm对称密钥大小，以及一个位字符串“SharedInfo”，它是ECC CMS SharedInfo的DER编码（见第8.2节）。然后，发送代理执行[SEC1，第6.1节]中规定的椭圆曲线Diffie-Hellman方案的密钥部署和密钥协商操作。因此，发送代理获得：
- an ephemeral public key, which is represented as a value of the type ECPoint (see Section 8.2), encapsulated in a bit string and placed in the KeyAgreeRecipientInfo originator field, and
- 临时公钥，表示为ECPoint类型的值（参见第8.2节），封装在位字符串中，并放置在KeyAgreeRecipientInfo发起人字段中，以及
- a shared secret bit string "K", which is used as the pairwise key-encryption key for that recipient, as specified in [CMS].
- 一个共享秘密位字符串“K”，用作该接收者的成对密钥加密密钥，如[CMS]中所述。
When using ephemeral-static ECDH with EnvelopedData, the receiving agent determines the bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC public key from the bit string KeyAgreeRecipientInfo originator, with a value of the type ECPoint (see Section 8.2) encapsulated as a bit string. The receiving agent performs the key agreement operation of the Elliptic Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As a result, the receiving agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key to unwrap the CEK.
当使用带有EnvelopedData的临时静态ECDH时，接收代理确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（参见第8.2节），以及KeyWrapAlgorithm的密钥大小（以位为单位）中的整数“keydatalen”。接收代理从位字符串KeyAgreeRecipientInfo发起者检索临时EC公钥，其值类型为ECPoint（见第8.2节），封装为位字符串。接收代理执行[SEC1，第6.1节]中规定的椭圆曲线Diffie-Hellman方案的密钥协商操作。结果，接收代理获得共享秘密比特串“K”，该比特串用作成对密钥加密密钥以打开CEK。
This section describes how to use the 1-Pass elliptic curve MQV (ECMQV) key agreement algorithm with EnvelopedData. ECMQV is specified in [SEC1] and [IEEE1363]. Like the KEA algorithm [CMS-KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a static key pair of the sending agent, and a static key pair of the receiving agent. An advantage of using 1-Pass ECMQV is that it can be used with both EnvelopedData and AuthenticatedData.
本节介绍如何在EnvelopedData中使用单通椭圆曲线MQV（ECMQV）密钥协商算法。[SEC1]和[IEEE1363]中规定了ECMQV。与KEA算法[CMS-KEA]一样，1-Pass ECMQV使用三个密钥对：临时密钥对、发送代理的静态密钥对和接收代理的静态密钥对。使用1-Pass ECMQV的一个优点是，它可以与EnvelopedData和AuthenticatedData一起使用。
In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData with key agreement, the following techniques and formats MUST be used.
在使用具有密钥协议的CMS EnvelopedData的1-Pass ECMQV的实现中，必须使用以下技术和格式。
When using 1-Pass ECMQV with EnvelopedData, the fields of KeyAgreeRecipientInfo are:
将1-Pass ECMQV与EnvelopedData一起使用时，KeyAgreeRecipientInfo的字段为：
originator identifies the static EC public key of the sender. It SHOULD be one of the alternatives, issuerAndSerialNumber or subjectKeyIdentifier, and point to one of the sending agent's certificates.
发起者识别发送者的静态EC公钥。它应该是备选方案之一，issuerAndSerialNumber或subjectKeyIdentifier，并指向发送代理的证书之一。
ukm MUST be present. The ukm field MUST contain an octet string which is the DER encoding of the type MQVuserKeyingMaterial (see Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey
ukm必须在场。ukm字段必须包含八位字节字符串，该字符串是MQVuserKeyingMaterial类型的DER编码（见第8.2节）。MQVuserKeyingMaterial临时发布
algorithm field MUST contain the id-ecPublicKey object identifier (see Section 8.1) with NULL parameters field. The MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST contain the DER-encoding of the ASN.1 type ECPoint (see Section 8.2) representing sending agent's ephemeral EC public key. The MQVuserKeyingMaterial addedukm field, if present, SHOULD contain an octet string of additional user keying material of the sending agent.
算法字段必须包含id ecPublicKey对象标识符（见第8.1节）和空参数字段。MQVuserKeyingMaterial ephemeralPublicKey字段必须包含代表发送代理的ephemeral EC公钥的ASN.1类型ECPoint的DER编码（请参见第8.2节）。MQVuserKeyingMaterial addedukm字段（如果存在）应包含发送代理的附加用户密钥材料的八位字节字符串。
keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-scheme algorithm identifier (see Section 8.1), with the parameters field KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric encryption algorithm used to encrypt the CEK with the KEK generated using the 1-Pass ECMQV algorithm.
keyEncryptionAlgorithm必须是mqvSinglePass-sha1kdf-scheme算法标识符（参见第8.1节），参数字段为KeyWrapAlgorithm。KeyWrapAlgorithm表示对称加密算法，用于使用使用1-Pass ECMQV算法生成的KEK对CEK进行加密。
When using 1-Pass ECMQV with EnvelopedData, the sending agent first obtains the recipient's EC public key and domain parameters, (e.g. from the recipient's certificate) and checks that the domain parameters are the same. The sending agent then determines an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key-size in bits, and also a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending agent then performs the key deployment and key agreement operations of the Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2]. As a result, the sending agent obtains:
将1-Pass ECMQV与EnvelopedData一起使用时，发送代理首先获取收件人的EC公钥和域参数（例如，从收件人的证书），并检查域参数是否相同。然后，发送代理确定一个整数“keydatalen”，它是以位为单位的KeyWrapAlgorithm对称密钥大小，以及一个位字符串“SharedInfo”，它是ECC CMS SharedInfo的DER编码（见第8.2节）。然后，发送代理执行[SEC1，第6.2节]中指定的椭圆曲线MQV方案的密钥部署和密钥协商操作。结果，发送代理获得：
- an ephemeral public key, which is represented as a value of type ECPoint (see Section 8.2), encapsulated in a bit string, placed in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field (see Section 8.2), and
- 临时公钥，表示为ECPoint类型的值（参见第8.2节），封装在位字符串中，放置在MQVuser KeyingMaterial临时公钥字段中（参见第8.2节），以及
- a shared secret bit string "K", which is used as the pairwise key-encryption key for that recipient, as specified in [CMS].
- 一个共享秘密位字符串“K”，用作该接收者的成对密钥加密密钥，如[CMS]中所述。
The ephemeral public key can be re-used with an AuthenticatedData for greater efficiency.
临时公钥可以与AuthenticatedData一起重新使用，以提高效率。
When using 1-Pass ECMQV with EnvelopedData, the receiving agent determines the bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields as described in Section 3.2.1, and its static EC public key identified in the rid
当将1-Pass ECMQV与EnvelopedData一起使用时，接收代理确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（参见第8.2节），并根据KeyWrapAlgorithm的密钥大小（以位为单位）确定整数“keydatalen”。然后，接收代理从第3.2.1节所述的发起人和ukm字段中检索发起人的静态和临时EC公钥，以及rid中标识的静态EC公钥
field and checks that the domain parameters are the same. The receiving agent then performs the key agreement operation of the Elliptic Curve MQV Scheme [SEC1, Section 6.2]. As a result, the receiving agent obtains a shared secret bit string "K" which is used as the pairwise key-encryption key to unwrap the CEK.
字段并检查域参数是否相同。然后，接收代理执行椭圆曲线MQV方案的密钥协商操作[SEC1，第6.2节]。结果，接收代理获得共享秘密比特串“K”，其用作成对密钥加密密钥以打开CEK。
4 AuthenticatedData using ECC
4使用ECC验证的数据
This section describes how to use ECC algorithms with the CMS AuthenticatedData format. AuthenticatedData lacks non-repudiation, and so in some instances is preferable to SignedData. (For example, the sending agent might not want the message to be authenticated when forwarded.)
本节介绍如何将ECC算法与CMS AuthenticatedData格式结合使用。AuthenticatedData缺乏不可否认性，因此在某些情况下比SignedData更可取。（例如，发送代理可能不希望在转发消息时对其进行身份验证。）
This section describes how to use the 1-Pass elliptic curve MQV (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is specified in [SEC1]. An advantage of using 1-Pass ECMQV is that it can be used with both EnvelopedData and AuthenticatedData.
本节介绍如何对AuthenticatedData使用单通道椭圆曲线MQV（ECMQV）密钥协商算法。ECMQV在[SEC1]中指定。使用1-Pass ECMQV的一个优点是，它可以与EnvelopedData和AuthenticatedData一起使用。
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
AuthenticatedData KeyAgreentRecipientInfo字段的使用方式与本文件第3.2.1节中相应EnvelopedData KeyAgreentRecipientInfo字段的使用方式相同。
The sending agent uses the same actions as for EnvelopedData with 1- Pass ECMQV, as specified in Section 3.2.2 of this document.
如本文档第3.2.2节所述，发送代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
The ephemeral public key can be re-used with an EnvelopedData for greater efficiency.
临时公钥可以与信封数据一起重新使用，以提高效率。
Note: if there are multiple recipients, an attack is possible where one recipient modifies the content without other recipients noticing [BON]. A sending agent who is concerned with such an attack SHOULD use a separate AuthenticatedData for each recipient.
注意：如果有多个收件人，一个收件人修改内容而其他收件人没有注意到[BON]的情况下，可能会发生攻击。与此类攻击有关的发送代理应为每个收件人使用单独的AuthenticatedData。
The receiving agent uses the same actions as for EnvelopedData with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
按照本文件第3.2.3节的规定，接收代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
Note: see Note in Section 4.1.2.
注：见第4.1.2节中的注释。
5 Recommended Algorithms and Elliptic Curves
5推荐算法和椭圆曲线
Implementations of this specification MUST implement either SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH. Implementations of this specification SHOULD implement both SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH. Implementations MAY implement the other techniques specified, such as AuthenticatedData and 1-Pass ECMQV.
本规范的实现必须使用ECDSA实现SignedData，或使用临时静态ECDH实现EnvelopedData。本规范的实现应使用ECDSA实现SignedData，使用临时静态ECDH实现EnvelopedData。实现可以实现指定的其他技术，例如AuthenticatedData和1-Pass ECMQV。
Furthermore, in order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by ANSI [X9.62], NIST [FIPS-186-2] and SECG [SEC2].
此外，为了鼓励互操作性，实现应使用ANSI[X9.62]、NIST[FIPS-186-2]和SECG[SEC2]指定的椭圆曲线域参数。
6 Certificates using ECC
6使用ECC的证书
Internet X.509 certificates [PKI] can be used in conjunction with this specification to distribute agents' public keys. The use of ECC algorithms and keys within X.509 certificates is specified in [PKI-ALG].
Internet X.509证书[PKI]可与本规范一起用于分发代理的公钥。[PKI-ALG]中规定了X.509证书中ECC算法和密钥的使用。
7 SMIMECapabilities Attribute and ECC
7 SMIMECapabilities属性和ECC
A sending agent MAY announce to receiving agents that it supports one or more of the ECC algorithms in this document by using the SMIMECapabilities signed attribute [MSG, Section 2.5.2].
发送代理可以使用SMIMECapabilities signed属性[MSG，第2.5.2节]向接收代理宣布其支持本文档中的一个或多个ECC算法。
The SMIMECapability value to indicate support for the ECDSA signature algorithm is the SEQUENCE with the capabilityID field containing the object identifier ecdsa-with-SHA1 with NULL parameters. The DER encoding is:
表示支持ECDSA签名算法的SMIMECapability值是capabilityID字段中包含对象标识符ECDSA-with-SHA1且参数为空的序列。DER编码是：
30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
The SMIMECapability capabilityID object identifiers for the supported key agreement algorithms in this document are dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass-cofactorDH-sha1kdf-scheme, and mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability SEQUENCEs, the parameters field is present and indicates the supported key-encryption algorithm with the KeyWrapAlgorithm algorithm identifier. The DER encodings that indicate capability of the three key agreement algorithms with CMS Triple-DES key wrap are:
本文档中支持的密钥协商算法的SMIMECapability Capability ID对象标识符为dhSinglePass-stdDH-sha1kdf-scheme、dhSinglePass-cofactorDH-sha1kdf-scheme和mqvSinglePass-sha1kdf-scheme。对于这些SMIMECapability序列中的每一个，参数字段都存在，并用KeyWrapAlgorithm算法标识符指示支持的密钥加密算法。表明三种密钥协商算法与CMS三重DES密钥包的能力的DER编码为：
30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
for ephemeral-static ECDH,
对于短暂静态ECDH，
30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
for ephemeral-static ECDH with cofactor method, and
对于带有辅助因子方法的短暂静态ECDH，以及
30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
for ECMQV.
对于ECMQV。
8 ASN.1 Syntax
8 ASN.1语法
The ASN.1 syntax used in this document is gathered in this section for reference purposes.
本节收集了本文档中使用的ASN.1语法，以供参考。
The algorithm identifiers used in this document are taken from [X9.62], [SEC1] and [SEC2].
本文档中使用的算法标识符取自[X9.62]、[SEC1]和[SEC2]。
The following object identifier indicates the hash algorithm used in this document:
以下对象标识符表示本文档中使用的哈希算法：
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The following object identifier is used in this document to indicate an elliptic curve public key:
本文档中使用以下对象标识符来表示椭圆曲线公钥：
id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }
id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }
where
哪里
ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
10045 }
ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
10045 }
When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain NULL.
当对象标识符id ecPublicKey在这里与算法标识符一起使用时，关联的参数包含NULL。
The following object identifier indicates the digital signature algorithm used in this document:
以下对象标识符表示本文档中使用的数字签名算法：
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4)
1 }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4)
1 }
When the object identifier ecdsa-with-SHA1 is used within an algorithm identifier, the associated parameters field contains NULL.
当在算法标识符中使用对象标识符ecdsa-with-SHA1时，关联的参数字段包含NULL。
The following object identifiers indicate the key agreement algorithms used in this document:
以下对象标识符表示本文档中使用的密钥协商算法：
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2}
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3}
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16}
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16}
where
哪里
x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
When the object identifiers are used here within an algorithm identifier, the associated parameters field contains the CMS KeyWrapAlgorithm algorithm identifier.
当在算法标识符中使用对象标识符时，关联参数字段包含CMS KeyWrapAlgorithm算法标识符。
The following additional syntax is used here.
这里使用以下附加语法。
When using ECDSA with SignedData, ECDSA signatures are encoded using the type:
将ECDSA与SignedData一起使用时，ECDSA签名使用以下类型进行编码：
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
ECDSA-Sig-Value is specified in [X9.62]. Within CMS, ECDSA-Sig-Value is DER-encoded and placed within a signature field of SignedData.
[X9.62]中规定了ECDSA Sig值。在CMS中，ECDSA Sig值被DER编码并放置在SignedData的签名字段中。
When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, ephemeral and static public keys are encoded using the type ECPoint.
在将ECDH和ECMQV与EnvelopedData和AuthenticatedData一起使用时，使用ECPoint类型对临时公钥和静态公钥进行编码。
ECPoint ::= OCTET STRING
ECPoint ::= OCTET STRING
When using ECMQV with EnvelopedData and AuthenticatedData, the sending agent's ephemeral public key and additional keying material are encoded using the type:
将ECMQV与EnvelopedData和AuthenticatedData一起使用时，发送代理的临时公钥和其他密钥资料将使用以下类型进行编码：
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The ECPoint syntax in used to represent the ephemeral public key and placed in the ephemeralPublicKey field. The additional user keying material is placed in the addedukm field. Then the MQVuserKeyingMaterial value is DER-encoded and placed within a ukm field of EnvelopedData or AuthenticatedData.
中的ECPoint语法用于表示临时公钥，并放置在临时公钥字段中。附加的用户关键点材质放置在addedukm字段中。然后对MQVuserKeyingMaterial值进行DER编码，并将其放置在EnvelopedData或AuthenticatedData的ukm字段中。
When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, the key-encryption keys are derived by using the type:
将ECDH或ECMQV与EnvelopedData或AuthenticatedData一起使用时，密钥加密密钥通过以下类型派生：
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 fields of ECC-CMS-SharedInfo are as follows:
ECC CMS SharedInfo的字段如下：
keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and NULL parameters.
keyInfo包含密钥加密算法的对象标识符（用于包装CEK）和空参数。
entityUInfo optionally contains additional keying material supplied by the sending agent. When used with ECDH and CMS, the entityUInfo field contains the octet string ukm. When used with ECMQV and CMS, the entityUInfo contains the octet string addedukm (encoded in MQVuserKeyingMaterial).
entityUInfo可选地包含发送代理提供的其他键控材料。当与ECDH和CMS一起使用时，entityUInfo字段包含八位字节字符串ukm。当与ECMQV和CMS一起使用时，entityUInfo包含八位字节字符串addedukm（以MQVuserKeyingMaterial编码）。
suppPubInfo contains the length of the generated KEK, in bits, represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES it would be 00 00 00 c0.)
suppPubInfo包含生成的KEK的长度，以位为单位，表示为32位数字，如[CMS-DH]中所示。（例如，对于3DES，它将是00 c0。）
Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to the key derivation function, as specified in [SEC1, Section 3.6.1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [CMS-DH]. Here, a counter value is not included in the keyInfo field because the key derivation function specified in [SEC1, Section 3.6.1] ensures that sufficient keying data is provided.
在CMS中，ECC CMS SharedInfo按照[SEC1，第3.6.1节]的规定进行顺序编码并用作密钥派生函数的输入。请注意，ECC CMS SharedInfo与[CMS-DH]中指定的其他信息不同。此处，由于[SEC1，第3.6.1节]中规定的密钥派生函数确保提供足够的密钥数据，因此keyInfo字段中不包括计数器值。
9 Summary
9摘要
This document specifies how to use ECC algorithms with the S/MIME CMS. Use of ECC algorithm within CMS can result in reduced processing requirements for S/MIME agents, and reduced bandwidth for CMS messages.
本文档指定了如何在S/MIME CMS中使用ECC算法。在CMS中使用ECC算法可以降低S/MIME代理的处理要求，并降低CMS消息的带宽。
References
工具书类
[X9.62] ANSI X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standards Institute, 1999.
[X9.62]ANSI X9.62-1998，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，美国国家标准协会，1999年。
[PKI-ALG] Bassham, L., Housley R. and W. Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 3279, April 2002.
[PKI-ALG]Bassham，L.，Housley R.和W.Polk，“互联网X.509公钥基础设施证书和CRL配置文件的算法和标识符”，RFC 3279，2002年4月。
[BON] D. Boneh, "The Security of Multicast MAC", Presentation
at Selected Areas of Cryptography 2000, Center for
Applied Cryptographic Research, University of Waterloo,
2000. Paper version available from
http://crypto.stanford.edu/~dabo/papers/mmac.ps
[BON] D. Boneh, "The Security of Multicast MAC", Presentation
at Selected Areas of Cryptography 2000, Center for
Applied Cryptographic Research, University of Waterloo,
2000. Paper version available from
http://crypto.stanford.edu/~dabo/papers/mmac.ps
[MUST] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[必须]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 21192997年3月。
[FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute of Standards and Technology, April 17, 1995.
[FIPS-180]FIPS 180-1，“安全哈希标准”，国家标准与技术研究所，1995年4月17日。
[FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National Institute of Standards and Technology, 15 February 2000.
[FIPS-186-2]FIPS 186-2，“数字签名标准”，国家标准与技术研究所，2000年2月15日。
[PKI] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKI]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 32802002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[IEEE1363] IEEE P1363, "Standard Specifications for Public Key Cryptography", Institute of Electrical and Electronics Engineers, 2000.
[IEEE1363]IEEE P1363，“公开密钥加密的标准规范”，电气和电子工程师协会，2000年。
[K] B. Kaliski, "MQV Vulnerabilty", Posting to ANSI X9F1 and IEEE P1363 newsgroups, 1998.
[K] B.Kaliski，“MQV漏洞”，发布到ANSI X9F1和IEEE P1363新闻组，1998年。
[LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An efficient protocol for authenticated key agreement", Technical report CORR 98-05, University of Waterloo, 1998.
[LMQSv] L. Law，A. Menezes，M. Qu，J. Solinas和S. Vanstone，“一个有效的认证密钥协议协议”，技术报告CORR 98－05，滑铁卢大学，1998。
[CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 2876, July 2000.
[CMS-KEA]Pawling，J.，“CMS-KEA和SKIPJACK公约”，RFC 28762000年7月。
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMS-DH]Rescorla，E.“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[SEC1] SECG, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group, 2000. Available from www.secg.org/collateral/sec1.pdf.
[SEC1]SECG，“椭圆曲线密码术”，高效密码组标准，2000年。可从www.secg.org/collateral/sec1.pdf获取。
[SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography Group, 2000. Available from www.secg.org/collateral/sec2.pdf.
[SEC2]SECG，“建议的椭圆曲线域参数”，高效密码组标准，2000年。可从www.secg.org/collateral/sec2.pdf获取。
Security Considerations
安全考虑
This specification is based on [CMS], [X9.62] and [SEC1] and the appropriate security considerations of those documents apply.
本规范以[CMS]、[X9.62]和[SEC1]为基础，适用这些文件的适当安全注意事项。
In addition, implementors of AuthenticatedData should be aware of the concerns expressed in [BON] when using AuthenticatedData to send messages to more than one recipient. Also, users of MQV should be aware of the vulnerability in [K].
此外，当使用AuthenticatedData向多个收件人发送消息时，AuthenticatedData的实现者应该知道[BON]中表达的问题。此外，MQV的用户应该知道[K]中的漏洞。
When 256, 384, and 512 bit hash functions succeed SHA-1 in future revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they can similarly succeed SHA-1 in a future revision of this document.
当256、384和512位哈希函数在[FIPS]、[FIPS-186-2]、[X9.62]和[SEC1]的未来版本中继承SHA-1时，它们也可以在本文档的未来版本中继承SHA-1。
Intellectual Property Rights
知识产权
The IETF has been notified of intellectual property rights claimed in regard to the specification contained in this document. For more information, consult the online list of claimed rights (http://www.ietf.org/ipr.html).
IETF已收到关于本文件所含规范的知识产权声明。有关更多信息，请查阅在线权利主张列表(http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP 11。可供发布的权利主张副本和任何许可证保证副本，或试图
obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
可从IETF秘书处获得本规范实施者或用户使用此类专有权利的一般许可或许可。
Acknowledgments
致谢
The methods described in this document are based on work done by the ANSI X9F1 working group. The authors wish to extend their thanks to ANSI X9F1 for their assistance. The authors also wish to thank Peter de Rooij for his patient assistance. The technical comments of Francois Rousseau were valuable contributions.
本文件中描述的方法基于ANSI X9F1工作组所做的工作。作者希望对ANSI X9F1的帮助表示感谢。作者还要感谢Peter de Rooij对患者的帮助。弗朗索瓦·卢梭的技术评论是宝贵的贡献。
Authors' Addresses
作者地址
Simon Blake-Wilson Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1
Simon Blake Wilson Certicom Corp 5520 Explorer Drive#400 Missisauga，位于L4W 5L1
EMail: sblakewi@certicom.com
EMail: sblakewi@certicom.com
Daniel R. L. Brown pCerticom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1
Daniel R.L.Brown pCerticom公司位于密西西比索加400号探索者大道5520号，L4W 5L1
EMail: dbrown@certicom.com
EMail: dbrown@certicom.com
Paul Lambert
保罗·兰伯特
EMail: plambert@sprintmail.com
EMail: plambert@sprintmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。