Network Working Group S. Blake-Wilson
Request for Comments: 4492 SafeNet
Category: Informational N. Bolyard
Sun Microsystems
V. Gupta
Sun Labs
C. Hawk
Corriente
B. Moeller
Ruhr-Uni Bochum
May 2006
Network Working Group S. Blake-Wilson
Request for Comments: 4492 SafeNet
Category: Informational N. Bolyard
Sun Microsystems
V. Gupta
Sun Labs
C. Hawk
Corriente
B. Moeller
Ruhr-Uni Bochum
May 2006
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
用于传输层安全（TLS）的椭圆曲线加密（ECC）密码套件
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.
本文档描述了用于传输层安全（TLS）协议的基于椭圆曲线密码（ECC）的新密钥交换算法。特别是，它规定了在TLS握手中使用椭圆曲线Diffie-Hellman（ECDH）密钥协议，以及使用椭圆曲线数字签名算法（ECDSA）作为一种新的身份验证机制。
Table of Contents
目录
1. Introduction ....................................................3
2. Key Exchange Algorithms .........................................4
2.1. ECDH_ECDSA .................................................6
2.2. ECDHE_ECDSA ................................................6
2.3. ECDH_RSA ...................................................7
2.4. ECDHE_RSA ..................................................7
2.5. ECDH_anon ..................................................7
3. Client Authentication ...........................................8
3.1. ECDSA_sign .................................................8
3.2. ECDSA_fixed_ECDH ...........................................9
3.3. RSA_fixed_ECDH .............................................9
4. TLS Extensions for ECC ..........................................9
5. Data Structures and Computations ...............................10
5.1. Client Hello Extensions ...................................10
5.1.1. Supported Elliptic Curves Extension ................12
5.1.2. Supported Point Formats Extension ..................13
5.2. Server Hello Extension ....................................14
5.3. Server Certificate ........................................15
5.4. Server Key Exchange .......................................17
5.5. Certificate Request .......................................21
5.6. Client Certificate ........................................22
5.7. Client Key Exchange .......................................23
5.8. Certificate Verify ........................................25
5.9. Elliptic Curve Certificates ...............................26
5.10. ECDH, ECDSA, and RSA Computations ........................26
6. Cipher Suites ..................................................27
7. Security Considerations ........................................28
8. IANA Considerations ............................................29
9. Acknowledgements ...............................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Equivalent Curves (Informative) ......................32
1. Introduction ....................................................3
2. Key Exchange Algorithms .........................................4
2.1. ECDH_ECDSA .................................................6
2.2. ECDHE_ECDSA ................................................6
2.3. ECDH_RSA ...................................................7
2.4. ECDHE_RSA ..................................................7
2.5. ECDH_anon ..................................................7
3. Client Authentication ...........................................8
3.1. ECDSA_sign .................................................8
3.2. ECDSA_fixed_ECDH ...........................................9
3.3. RSA_fixed_ECDH .............................................9
4. TLS Extensions for ECC ..........................................9
5. Data Structures and Computations ...............................10
5.1. Client Hello Extensions ...................................10
5.1.1. Supported Elliptic Curves Extension ................12
5.1.2. Supported Point Formats Extension ..................13
5.2. Server Hello Extension ....................................14
5.3. Server Certificate ........................................15
5.4. Server Key Exchange .......................................17
5.5. Certificate Request .......................................21
5.6. Client Certificate ........................................22
5.7. Client Key Exchange .......................................23
5.8. Certificate Verify ........................................25
5.9. Elliptic Curve Certificates ...............................26
5.10. ECDH, ECDSA, and RSA Computations ........................26
6. Cipher Suites ..................................................27
7. Security Considerations ........................................28
8. IANA Considerations ............................................29
9. Acknowledgements ...............................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Equivalent Curves (Informative) ......................32
Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments. Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes. This is illustrated in the following table, based on [18], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them.
椭圆曲线密码（ECC）是一种新兴的公钥密码系统，特别是在移动（即无线）环境中。与当前流行的密码系统（如RSA）相比，ECC以较小的密钥大小提供了同等的安全性。下表基于[18]对此进行了说明，该表给出了对称和非对称密钥密码系统的近似可比密钥大小，这些密钥大小基于最著名的攻击算法。
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable Key Sizes (in bits)
表1：可比密钥大小（以位为单位）
Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments.
较小的密钥大小可以节省电源、内存、带宽和计算成本，这使得ECC对于受限环境特别有吸引力。
This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines
本文件描述了TLS中支持ECC的新增内容，适用于TLS版本1.0[2]和TLS版本1.1[3]。特别是，它定义了
o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme with long-term or ephemeral keys to establish the TLS premaster secret, and
o 使用具有长期或短暂密钥的椭圆曲线Diffie-Hellman（ECDH）密钥协商方案来建立TLS premaster密钥，以及
o the use of fixed-ECDH certificates and ECDSA for authentication of TLS peers.
o 使用固定ECDH证书和ECDSA对TLS对等方进行身份验证。
The remainder of this document is organized as follows. Section 2 provides an overview of ECC-based key exchange algorithms for TLS. Section 3 describes the use of ECC certificates for client authentication. TLS extensions that allow a client to negotiate the use of specific curves and point formats are presented in Section 4. Section 5 specifies various data structures needed for an ECC-based handshake, their encoding in TLS messages, and the processing of those messages. Section 6 defines new ECC-based cipher suites and identifies a small subset of these as recommended for all implementations of this specification. Section 7 discusses security considerations. Section 8 describes IANA considerations for the name spaces created by this document. Section 9 gives acknowledgements.
本文件的其余部分组织如下。第2节概述了基于ECC的TLS密钥交换算法。第3节介绍了ECC证书在客户端身份验证中的使用。第4节介绍了允许客户协商使用特定曲线和点格式的TLS扩展。第5节规定了基于ECC的握手所需的各种数据结构、它们在TLS消息中的编码以及这些消息的处理。第6节定义了新的基于ECC的密码套件，并根据本规范的所有实施建议确定了其中的一小部分。第7节讨论了安全注意事项。第8节描述了本文档创建的名称空间的IANA注意事项。第9节给出了确认。
This is followed by the lists of normative and informative references cited in this document, the authors' contact information, and statements on intellectual property rights and copyrights.
随后是本文件引用的规范性和信息性参考文献清单、作者联系信息以及关于知识产权和版权的声明。
Implementation of this specification requires familiarity with TLS [2][3], TLS extensions [4], and ECC [5][6][7][11][17].
本规范的实施要求熟悉TLS[2][3]、TLS扩展[4]和ECC[5][6][7][11][17]。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document introduces five new ECC-based key exchange algorithms for TLS. All of them use ECDH to compute the TLS premaster secret, and they differ only in the lifetime of ECDH keys (long-term or ephemeral) and the mechanism (if any) used to authenticate them. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC.
本文介绍了五种新的基于ECC的TLS密钥交换算法。它们都使用ECDH来计算TLS premaster机密，并且它们仅在ECDH密钥的生命周期（长期或短暂）以及用于对其进行身份验证的机制（如果有）方面有所不同。TLS主密钥从主密钥前的密钥派生以及随后生成的批量加密/MAC密钥和初始化向量独立于密钥交换算法，不受ECC引入的影响。
The table below summarizes the new key exchange algorithms, which mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and [3]), respectively.
下表总结了新的密钥交换算法，它们分别模拟DH_DSS、DHE_DSS、DH_RSA、DHE_RSA和DH_anon（参见[2]和[3]）。
Key
Exchange
Algorithm Description
--------- -----------
Key
Exchange
Algorithm Description
--------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDH_ECDSA使用ECDSA签名证书修复了ECDH。
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDHE_ECDSA带有ECDSA签名的短暂ECDH。
ECDH_RSA Fixed ECDH with RSA-signed certificates.
ECDH_RSA修复了带有RSA签名证书的ECDH。
ECDHE_RSA Ephemeral ECDH with RSA signatures.
ECDHE_RSA带有RSA签名的临时ECDH。
ECDH_anon Anonymous ECDH, no signatures.
ECDH_anon匿名ECDH，无签名。
Table 2: ECC Key Exchange Algorithms
表2:ECC密钥交换算法
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see Section 4). However, the computational cost
ECDHE_ECDSA和ECDHE_RSA密钥交换机制提供前向保密性。使用ECDHE_RSA，服务器可以重用其现有的RSA证书，并轻松遵守受约束客户端的椭圆曲线首选项（请参见第4节）。然而，计算成本
incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy.
ECDHE_RSA在服务器上的开销高于传统RSA密钥交换，后者不提供前向保密性。
The ECDH_RSA mechanism requires a server to acquire an ECC certificate, but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the keys of trusted certification authorities accepted by TLS clients. The ECDH_ECDSA mechanism requires ECC keys for the server as well as the certification authority and is best suited for constrained devices unable to support RSA.
ECDH_RSA机制要求服务器获取ECC证书，但证书颁发者仍可使用现有RSA密钥进行签名。这样就无需更新TLS客户端接受的可信证书颁发机构的密钥。ECDH_ECDSA机制需要服务器和证书颁发机构的ECC密钥，最适合于无法支持RSA的受限设备。
The anonymous key exchange algorithm does not provide authentication of the server or the client. Like other anonymous TLS key exchanges, it is subject to man-in-the-middle attacks. Implementations of this algorithm SHOULD provide authentication by other means.
匿名密钥交换算法不提供服务器或客户端的身份验证。与其他匿名TLS密钥交换一样，它也会受到中间人攻击。此算法的实现应通过其他方式提供身份验证。
Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations [15]. This document refers to an ECC key as ECDH-capable if its use in ECDH is permitted. ECDSA-capable is defined similarly.
请注意，ECDH和ECDSA键之间没有结构差异。证书颁发者可以使用X.509 v3密钥使用和extendedKeyUsage扩展，将ECC公钥的使用限制在某些计算中[15]。如果允许在ECDH中使用，本文件将ECC密钥称为ECDH功能密钥。ECDSA能力的定义与此类似。
Client Server
------ ------
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Application Data <-------> Application Data
* message is not sent under some conditions + message is not sent unless client authentication is desired
* 在某些情况下不发送消息+除非需要客户端身份验证，否则不发送消息
Figure 1: Message flow in a full TLS handshake
图1：完整TLS握手中的消息流
Figure 1 shows all messages involved in the TLS key establishment protocol (aka full handshake). The addition of ECC has direct impact only on the ClientHello, the ServerHello, the server's Certificate message, the ServerKeyExchange, the ClientKeyExchange, the CertificateRequest, the client's Certificate message, and the CertificateVerify. Next, we describe each ECC key exchange algorithm in greater detail in terms of the content and processing of these messages. For ease of exposition, we defer discussion of client authentication and associated messages (identified with a + in Figure 1) until Section 3 and of the optional ECC-specific extensions (which impact the Hello messages) until Section 4.
图1显示了TLS密钥建立协议（也称为完全握手）中涉及的所有消息。ECC的添加仅对ClientHello、ServerHello、服务器的证书消息、ServerKeyExchange、ClientKeyExchange、CertificateRequest、客户端的证书消息和CertificateVerify有直接影响。接下来，我们将从这些消息的内容和处理方面更详细地描述每个ECC密钥交换算法。为了便于说明，我们将客户机身份验证和相关消息（图1中用a+标识）的讨论推迟到第3节，将可选的ECC特定扩展（影响Hello消息）的讨论推迟到第4节。
In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA.
在ECDH_ECDSA中，服务器的证书必须包含支持ECDH的公钥，并使用ECDSA签名。
A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret).
不得发送ServerKeyExchange（服务器证书包含客户端获取premaster机密所需的所有必要密钥信息）。
The client generates an ECDH key pair on the same curve as the server's long-term public key and sends its public key in the ClientKeyExchange message (except when using client authentication algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section 3.3 apply).
客户端在与服务器长期公钥相同的曲线上生成ECDH密钥对，并在ClientKeyExchange消息中发送其公钥（使用客户端身份验证算法ECDSA_fixed_ECDH或RSA_fixed_ECDH时除外，在这种情况下，第3.2节或第3.3节的修改适用）。
Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10.
客户端和服务器都执行ECDH操作，并将结果共享机密用作premaster机密。按照第5.10节的规定进行所有ECDH计算。
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
在ECDHE_ECDSA中，服务器的证书必须包含支持ECDSA的公钥，并使用ECDSA签名。
The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST be signed with ECDSA using the private key corresponding to the public key in the server's Certificate.
服务器发送其临时ECDH公钥和ServerKeyExchange消息中相应曲线的规范。必须使用与服务器证书中的公钥对应的私钥，使用ECDSA对这些参数进行签名。
The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message.
客户端在与服务器临时ECDH密钥相同的曲线上生成ECDH密钥对，并在ClientKeyExchange消息中发送其公钥。
Both client and server perform an ECDH operation (Section 5.10) and use the resultant shared secret as the premaster secret.
客户端和服务器都执行ECDH操作（第5.10节），并将生成的共享密钥用作主密钥。
This key exchange algorithm is the same as ECDH_ECDSA except that the server's certificate MUST be signed with RSA rather than ECDSA.
此密钥交换算法与ECDH_ECDSA相同，只是服务器的证书必须使用RSA而不是ECDSA签名。
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key. The server certificate MUST be signed with RSA.
此密钥交换算法与ECDHE_ECDSA相同，只是服务器的证书必须包含授权签名的RSA公钥，并且必须使用相应的RSA私钥计算ServerKeyExchange消息中的签名。服务器证书必须使用RSA签名。
In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent.
在ECDH_anon中，不得发送服务器的证书、CertificateRequest、客户端的证书和CertificateVerify消息。
The server MUST send an ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST NOT be signed.
服务器必须在ServerKeyExchange消息中发送临时ECDH公钥和相应曲线的规范。不得对这些参数进行签名。
The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message.
客户端在与服务器临时ECDH密钥相同的曲线上生成ECDH密钥对，并在ClientKeyExchange消息中发送其公钥。
Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10.
客户端和服务器都执行ECDH操作，并将结果共享机密用作premaster机密。按照第5.10节的规定进行所有ECDH计算。
Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.)
请注意，虽然ECDH_ECDSA、ECDHE_ECDSA、ECDH_RSA和ECDHE_RSA密钥交换算法要求使用特定的签名方案对服务器的证书进行签名，但本规范（遵循[2]和[3]中DH_DSS、DHE_DSS、DH_RSA和DHE_RSA的类似情况）不会对证书链中其他位置使用的签名方案施加限制。（此类限制通常是有用的，预计在认证机构的签名实践中会考虑到这一点。但是，通常并不严格要求此类限制：即使客户端无法完全验证给定链，客户端也可能能够验证服务器的ce通过依赖可信的证书颁发机构进行证书颁发，该机构的证书显示为链中的中间证书之一。）
This document defines three new client authentication mechanisms, each named after the type of client certificate involved: ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. The ECDSA_sign mechanism is usable with any of the non-anonymous ECC key exchange algorithms described in Section 2 as well as other non-anonymous (non-ECC) key exchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the use of a long-term ECDH client key would jeopardize the forward secrecy property of these algorithms.
本文档定义了三种新的客户端身份验证机制，每种机制都以涉及的客户端证书类型命名：ECDSA_sign、ECDSA_fixed_ECDH和RSA_fixed_ECDH。ECDSA_签名机制可用于第2节中描述的任何非匿名ECC密钥交换算法以及TLS[2][3]中定义的其他非匿名（非ECC）密钥交换算法。ECDSA_fixed_ECDH和RSA_fixed_ECDH机制可用于ECDH_ECDSA和ECDH_RSA。禁止将其与ECDHE_ECDSA和ECDHE_RSA一起使用，因为使用长期ECDH客户端密钥将危及这些算法的前向保密性。
The server can request ECC-based client authentication by including one or more of these certificate types in its CertificateRequest message. The server must not include any certificate types that are prohibited for the negotiated key exchange algorithm. The client must check if it possesses a certificate appropriate for any of the methods suggested by the server and is willing to use it for authentication.
服务器可以通过在其CertificateRequest消息中包含一种或多种证书类型来请求基于ECC的客户端身份验证。服务器不得包含协商密钥交换算法禁止的任何证书类型。客户端必须检查是否拥有适合服务器建议的任何方法的证书，并愿意将其用于身份验证。
If these conditions are not met, the client should send a client Certificate message containing no certificates. In this case, the ClientKeyExchange should be sent as described in Section 2, and the CertificateVerify should not be sent. If the server requires client authentication, it may respond with a fatal handshake failure alert.
如果不满足这些条件，则客户端应发送不包含任何证书的客户端证书消息。在这种情况下，应按照第2节所述发送ClientKeyExchange，而不应发送CertificateVerify。如果服务器需要客户端身份验证，它可能会发出致命的握手失败警报。
If the client has an appropriate certificate and is willing to use it for authentication, it must send that certificate in the client's Certificate message (as per Section 5.6) and prove possession of the private key corresponding to the certified key. The process of determining an appropriate certificate and proving possession is different for each authentication mechanism and described below.
如果客户拥有适当的证书并愿意将其用于身份验证，则必须在客户的证书消息中发送该证书（根据第5.6节），并证明拥有与认证密钥对应的私钥。对于每种认证机制，确定适当证书和证明占有的过程是不同的，如下所述。
NOTE: It is permissible for a server to request (and the client to send) a client certificate of a different type than the server certificate.
注意：允许服务器请求（和客户端发送）与服务器证书不同类型的客户端证书。
To use this authentication mechanism, the client MUST possess a certificate containing an ECDSA-capable public key and signed with ECDSA.
要使用此身份验证机制，客户端必须拥有一个包含支持ECDSA的公钥并使用ECDSA签名的证书。
The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify message as described in Section 5.8.
如第5.8节所述，客户通过在CertificateVerify消息中包含签名来证明拥有与认证密钥相对应的私钥。
To use this authentication mechanism, the client MUST possess a certificate containing an ECDH-capable public key, and that certificate MUST be signed with ECDSA. Furthermore, the client's ECDH key MUST be on the same elliptic curve as the server's long-term (certified) ECDH key. This might limit use of this mechanism to closed environments. In situations where the client has an ECC key on a different curve, it would have to authenticate using either ECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for both servers and clients is computationally more efficient than mechanisms providing forward secrecy.
要使用此身份验证机制，客户端必须拥有一个包含支持ECDH的公钥的证书，并且该证书必须使用ECDSA签名。此外，客户端的ECDH密钥必须与服务器的长期（认证）ECDH密钥位于同一椭圆曲线上。这可能会将此机制的使用限制在封闭环境中。如果客户端的ECC密钥位于不同的曲线上，则必须使用ECDSA_签名或非ECC机制（例如RSA）进行身份验证。对服务器和客户端使用固定ECDH在计算上比提供前向保密的机制更有效。
When using this authentication mechanism, the client MUST send an empty ClientKeyExchange as described in Section 5.7 and MUST NOT send the CertificateVerify message. The ClientKeyExchange is empty since the client's ECDH public key required by the server to compute the premaster secret is available inside the client's certificate. The client's ability to arrive at the same premaster secret as the server (demonstrated by a successful exchange of Finished messages) proves possession of the private key corresponding to the certified public key, and the CertificateVerify message is unnecessary.
使用此身份验证机制时，客户端必须发送第5.7节所述的空ClientKeyExchange，并且不得发送CertificateVerify消息。ClientKeyExchange为空，因为服务器计算premaster机密所需的客户端ECDH公钥在客户端证书中可用。客户端获得与服务器相同的主密钥的能力（通过成功交换完成的消息证明）证明拥有与认证公钥相对应的私钥，而CertificateVerify消息是不必要的。
This authentication mechanism is identical to ECDSA_fixed_ECDH except that the client's certificate MUST be signed with RSA.
此身份验证机制与ECDSA_fixed_ECDH相同，只是客户端的证书必须使用RSA签名。
Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH client authentication mechanisms require the client's certificate to be signed with a particular signature scheme, this specification does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a server to completely validate a given chain, the server may be able to validate the clients certificate by relying on a trust anchor that appears as one of the intermediate certificates in the chain.)
请注意，虽然ECDSA_签名、ECDSA_fixed_ECDH和RSA_fixed_ECDH客户端身份验证机制要求使用特定的签名方案对客户端的证书进行签名，但本规范并未对证书链中其他位置使用的签名方案施加限制。（此类限制通常是有用的，并且预计在认证机构的签名实践中会考虑到这一点。但是，通常并不严格要求此类限制：即使服务器无法完全验证给定链，服务器也可能能够验证客户端。）t通过依赖作为链中的中间证书之一出现的信任锚点进行认证。）
Two new TLS extensions are defined in this specification: (i) the Supported Elliptic Curves Extension, and (ii) the Supported Point Formats Extension. These allow negotiating the use of specific curves and point formats (e.g., compressed vs. uncompressed, respectively) during a handshake starting a new session. These extensions are especially relevant for constrained clients that may
本规范中定义了两个新的TLS扩展：（i）支持的椭圆曲线扩展，（ii）支持的点格式扩展。这些允许在握手开始新会话期间协商使用特定曲线和点格式（例如，分别为压缩和未压缩）。这些扩展尤其适用于可能出现以下情况的受限客户端：
only support a limited number of curves or point formats. They follow the general approach outlined in [4]; message details are specified in Section 5. The client enumerates the curves it supports and the point formats it can parse by including the appropriate extensions in its ClientHello message. The server similarly enumerates the point formats it can parse by including an extension in its ServerHello message.
仅支持有限数量的曲线或点格式。它们遵循[4]中概述的一般方法；第5节规定了消息的详细信息。客户端通过在其ClientHello消息中包含适当的扩展来枚举它支持的曲线和它可以解析的点格式。服务器通过在其ServerHello消息中包含扩展来枚举它可以解析的点格式。
A TLS client that proposes ECC cipher suites in its ClientHello message SHOULD include these extensions. Servers implementing ECC cipher suites MUST support these extensions, and when a client uses these extensions, servers MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves and compression techniques specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client's inability to deal with the server's EC key.
CLIELLO建议将这些消息扩展包含在其CLIELLA密码套件中。实现ECC密码套件的服务器必须支持这些扩展，并且当客户端使用这些扩展时，服务器不得协商ECC密码套件的使用，除非它们能够在遵守客户端指定的曲线和压缩技术选择的同时完成握手。这消除了协商ECC握手随后由于客户端无法处理服务器的EC密钥而中止的可能性。
The client MUST NOT include these extensions in the ClientHello message if it does not propose any ECC cipher suites. A client that proposes ECC cipher suites may choose not to include these extensions. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5. That section also describes the structure and processing of these extensions in greater detail.
如果客户机未提出任何ECC密码套件，则不得在ClientHello消息中包含这些扩展。提出ECC密码套件的客户机可以选择不包括这些扩展。在这种情况下，服务器可以自由选择第5节中列出的任何一种椭圆曲线或点格式。该部分还更详细地描述了这些扩展的结构和处理。
In the case of session resumption, the server simply ignores the Supported Elliptic Curves Extension and the Supported Point Formats Extension appearing in the current ClientHello message. These extensions only play a role during handshakes negotiating a new session.
在会话恢复的情况下，服务器只会忽略当前ClientHello消息中显示的支持的椭圆曲线扩展和支持的点格式扩展。这些扩展只在握手协商新会话时起作用。
This section specifies the data structures and computations used by ECC-based key mechanisms specified in Sections 2, 3, and 4. The presentation language used here is the same as that used in TLS [2][3]. Since this specification extends TLS, these descriptions should be merged with those in the TLS specification and any others that extend TLS. This means that enum types may not specify all possible values, and structures with multiple formats chosen with a select() clause may not indicate all possible cases.
本节规定了第2节、第3节和第4节规定的基于ECC的密钥机制所使用的数据结构和计算。此处使用的表示语言与TLS[2][3]中使用的表示语言相同。由于本规范扩展了TLS，因此这些描述应与TLS规范中的描述以及扩展TLS的任何其他描述合并。这意味着枚举类型可能不会指定所有可能的值，使用select（）子句选择多种格式的结构可能不会指示所有可能的情况。
This section specifies two TLS extensions that can be included with the ClientHello message as described in [4], the Supported Elliptic Curves Extension and the Supported Point Formats Extension.
本节指定了[4]中所述的ClientHello消息中可以包含的两个TLS扩展，即支持的椭圆曲线扩展和支持的点格式扩展。
When these extensions are sent:
发送这些扩展时：
The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites.
扩展应与提出ECC密码套件的任何ClientHello消息一起发送。
Meaning of these extensions:
这些扩展的含义：
These extensions allow a client to enumerate the elliptic curves it supports and/or the point formats it can parse.
这些扩展允许客户端枚举它支持的椭圆曲线和/或它可以解析的点格式。
Structure of these extensions:
这些扩展的结构：
The general structure of TLS extensions is described in [4], and this specification adds two new types to ExtensionType.
TLS扩展的一般结构如[4]所述，本规范向ExtensionType添加了两个新类型。
enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType;
enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType;
elliptic_curves (Supported Elliptic Curves Extension): Indicates the set of elliptic curves supported by the client. For this extension, the opaque extension_data field contains EllipticCurveList. See Section 5.1.1 for details.
椭圆曲线（支持的椭圆曲线扩展）：表示客户端支持的椭圆曲线集。对于此扩展，不透明扩展_数据字段包含EllipticCurveList。详见第5.1.1节。
ec_point_formats (Supported Point Formats Extension): Indicates the set of point formats that the client can parse. For this extension, the opaque extension_data field contains ECPointFormatList. See Section 5.1.2 for details.
ec_point_formats（支持的点格式扩展）：指示客户端可以解析的点格式集。对于此扩展，不透明扩展_数据字段包含ECPointFormatList。详见第5.1.2节。
Actions of the sender:
发件人的操作：
A client that proposes ECC cipher suites in its ClientHello message appends these extensions (along with any others), enumerating the curves it supports and the point formats it can parse. Clients SHOULD send both the Supported Elliptic Curves Extension and the Supported Point Formats Extension. If the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats.
在ClientHello消息中提出ECC密码套件的客户端会附加这些扩展（以及其他扩展），列举它支持的曲线和它可以解析的点格式。客户端应发送支持的椭圆曲线扩展名和支持的点格式扩展名。如果确实发送了受支持的点格式扩展，则它必须包含值0（未压缩），作为点格式列表中的一项。
Actions of the receiver:
接收方的行动：
A server that receives a ClientHello containing one or both of these extensions MUST use the client's enumerated capabilities to guide its selection of an appropriate cipher suite. One of the proposed ECC cipher suites must be negotiated only if the server can successfully complete the handshake while using the curves and point formats supported by the client (cf. Sections 5.3 and 5.4).
接收包含一个或两个扩展的ClientHello的服务器必须使用客户端的枚举功能来指导其选择适当的密码套件。只有当服务器能够在使用客户端支持的曲线和点格式时成功完成握手时，才能协商其中一个建议的ECC密码套件（参见第5.3节和第5.4节）。
NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message. The server must consider the extensions in both cases.
注意：参与ECDHE-ECDSA密钥交换的服务器可能会对（i）其证书中的ECDSA密钥和（ii）ServerKeyExchange消息中的临时ECDH密钥使用不同的曲线。服务器必须考虑这两种情况下的扩展。
If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. Depending on what other cipher suites are proposed by the client and supported by the server, this may result in a fatal handshake failure alert due to the lack of common cipher suites.
如果服务器不理解支持的椭圆曲线扩展、不理解支持的点格式扩展，或者无法完成ECC握手，同时将自身限制为枚举曲线和点格式，则不得协商ECC密码套件的使用。根据客户端提出并由服务器支持的其他密码套件，这可能会由于缺少通用密码套件而导致致命的握手失败警报。
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
reserved (0xFE00..0xFEFF),
arbitrary_explicit_prime_curves(0xFF01),
arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF)
} NamedCurve;
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
reserved (0xFE00..0xFEFF),
arbitrary_explicit_prime_curves(0xFF01),
arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF)
} NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves. The named curves defined here are those specified in SEC 2 [13]. Note that many of these curves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [11]. Values 0xFE00 through 0xFEFF are reserved for private use. Values 0xFF01 and 0xFF02 indicate that the client supports arbitrary prime and characteristic-2 curves, respectively (the curve parameters must be encoded explicitly in ECParameters).
sect163k1等：表示支持相应的命名曲线或明确定义的曲线类。此处定义的命名曲线为第2节[13]中规定的曲线。请注意，ANSI X9.62[7]和FIPS 186-2[11]中也推荐了许多此类曲线。值0xFE00到0xFEFF保留供私人使用。值0xFF01和0xFF02分别表示客户端支持任意素数和特征-2曲线（曲线参数必须在ECParameters中显式编码）。
The NamedCurve name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
NamedCurve名称空间由IANA维护。有关如何添加新值分配的信息，请参见第8节。
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's preferences (favorite choice first).
椭圆曲线列表中的项目根据客户的偏好排序（首选项优先）。
As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting of the following octets. Note that the first two octets indicate the extension type (Supported Elliptic Curves Extension):
例如，仅支持secp192r1（又名NIST P-192；值19=0x0013）和SECP24R1（又名NIST P-224；值21=0x0015）且更愿意使用secp192r1的客户机将包括由以下八位字节组成的TLS扩展。请注意，前两个八位字节表示扩展类型（支持的椭圆曲线扩展）：
00 0A 00 06 00 04 00 13 00 15
00 0A 00 06 00 04 00 13 00 15
A client that supports arbitrary explicit characteristic-2 curves (value 0xFF02) would include an extension consisting of the following octets:
支持任意显式characteristic-2曲线（值0xFF02）的客户端将包括由以下八位字节组成的扩展：
00 0A 00 04 00 02 FF 02
00 0A 00 04 00 02 FF 02
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Three point formats are included in the definition of ECPointFormat above. The uncompressed point format is the default format in that implementations of this document MUST support it for all of their supported curves. Compressed point formats reduce bandwidth by including only the x-coordinate and a single bit of the y-coordinate of the point. Implementations of this document MAY support the ansiX962_compressed_prime and ansiX962_compressed_char2 formats, where the former applies only to prime curves and the latter applies only to characteristic-2 curves. (These formats are specified in [7].) Values 248 through 255 are reserved for private use.
以上ECPointFormat的定义包括三种点格式。未压缩点格式是默认格式，因为本文档的实现必须支持其所有受支持的曲线。压缩点格式通过仅包含点的x坐标和y坐标的单个位来减少带宽。本文件的实施可能支持ansiX962_compressed_prime和ansiX962_compressed_char2格式，其中前者仅适用于prime曲线，后者仅适用于characteristic-2曲线。（这些格式在[7]中指定）248到255的值保留供私人使用。
The ECPointFormat name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
ECPointFormat名称空间由IANA维护。有关如何添加新值分配的信息，请参见第8节。
Items in ec_point_format_list are ordered according to the client's preferences (favorite choice first).
ec_point_format_列表中的项目根据客户的偏好排序（首选项）。
A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension):
仅能解析未压缩点格式（值0）的客户端包括由以下八位字节组成的扩展；请注意，前两个八位字节表示扩展类型（支持的点扩展格式）：
00 0B 00 02 01 00
00 0B 00 02 01 00
A client that in the case of prime fields prefers the compressed format (ansiX962_compressed_prime, value 1) over the uncompressed format (value 0), but in the case of characteristic-2 fields prefers the uncompressed format (value 0) over the compressed format (ansiX962_compressed_char2, value 2), may indicate these preferences by including an extension consisting of the following octets:
一种客户端，在素数字段的情况下，与未压缩格式（值0）相比，更喜欢压缩格式（ansiX962_compressed_prime，值1），但在characteristic-2字段的情况下，与压缩格式（ansiX962_compressed_char2，值2）相比，更喜欢未压缩格式（值0），可通过包括由以下八位字节组成的扩展来指示这些首选项：
00 0B 00 04 03 01 00 02
00 0B 00 04 03 01 00 02
This section specifies a TLS extension that can be included with the ServerHello message as described in [4], the Supported Point Formats Extension.
本节指定了一个TLS扩展，该扩展可以包含在ServerHello消息中，如[4]中所述，该扩展是受支持的点格式扩展。
When this extension is sent:
发送此扩展时：
The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite.
协商ECC密码套件时，支持的点格式扩展包含在ServerHello消息中，以响应包含支持的点格式扩展的ClientHello消息。
Meaning of this extension:
本扩展的含义：
This extension allows a server to enumerate the point formats it can parse (for the curve that will appear in its ServerKeyExchange message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key exchange algorithm, or for the curve that is used in the server's public key that will appear in its Certificate message when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
此扩展允许服务器枚举它可以解析的点格式（对于使用ECDHE_ECDSA、ECDHE_RSA或ECDH_anon密钥交换算法时将出现在其ServerKeyExchange消息中的曲线，或者对于使用ECDH_ECDSA或ECDH_RSA密钥交换算法时将出现在其证书消息中的服务器公钥中使用的曲线）。
Structure of this extension:
此扩展的结构：
The server's Supported Point Formats Extension has the same structure as the client's Supported Point Formats Extension (see Section 5.1.2). Items in elliptic_curve_list here are ordered according to the server's preference (favorite choice first). Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format).
服务器支持的点格式扩展与客户端支持的点格式扩展具有相同的结构（参见第5.1.2节）。椭圆曲线列表中的项目根据服务器的首选项排序（首选项优先）。请注意，服务器可能包括在客户端列表中找不到的项目（例如，即使客户端无法解析此格式，服务器也可能更喜欢接收压缩格式的点：尽管如此，同一客户端可能能够以压缩格式输出点）。
Actions of the sender:
发件人的操作：
A server that selects an ECC cipher suite in response to a ClientHello message including a Supported Point Formats Extension appends this extension (along with others) to its ServerHello message, enumerating the point formats it can parse. The Supported Point Formats Extension, when used, MUST contain the value 0 (uncompressed) as one of the items in the list of point formats.
选择ECC密码套件以响应ClientHello消息（包括受支持的点格式扩展）的服务器会将此扩展（以及其他扩展）附加到其ServerHello消息，枚举其可以解析的点格式。使用支持的点格式扩展时，必须将值0（未压缩）包含为点格式列表中的一个项目。
Actions of the receiver:
接收方的行动：
A client that receives a ServerHello message containing a Supported Point Formats Extension MUST respect the server's choice of point formats during the handshake (cf. Sections 5.6 and 5.7). If no Supported Point Formats Extension is received with the ServerHello, this is equivalent to an extension allowing only the uncompressed point format.
接收到包含支持的点格式扩展的ServerHello消息的客户端必须尊重服务器在握手期间对点格式的选择（参见第5.6和5.7节）。如果ServerHello未接收到支持的点格式扩展，则这相当于只允许未压缩点格式的扩展。
When this message is sent:
发送此消息时：
This message is sent in all non-anonymous ECC-based key exchange algorithms.
此消息在所有基于非匿名ECC的密钥交换算法中发送。
Meaning of this message:
此信息的含义：
This message is used to authentically convey the server's static public key to the client. The following table shows the server certificate type appropriate for each key exchange algorithm. ECC public keys MUST be encoded in certificates as described in Section 5.9.
此消息用于将服务器的静态公钥真实地传递给客户端。下表显示了适用于每个密钥交换算法的服务器证书类型。ECC公钥必须按照第5.9节所述在证书中进行编码。
NOTE: The server's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 3 apply only to the server's certificate (first in the chain).
注意：服务器的证书消息能够承载证书链。表3中提到的限制仅适用于服务器的证书（链中的第一个）。
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
ECDH_ECDSA Certificate MUST contain an ECDH-capable public key. It MUST be signed with ECDSA.
ECDH_ECDSA证书必须包含支持ECDH的公钥。必须与ECDSA签署。
ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. It MUST be signed with ECDSA.
ECDHE_ECDSA证书必须包含支持ECDSA的公钥。必须与ECDSA签署。
ECDH_RSA Certificate MUST contain an ECDH-capable public key. It MUST be signed with RSA.
ECDH必须包含支持RSA的公钥。它必须用RSA签名。
ECDHE_RSA Certificate MUST contain an RSA public key authorized for use in digital signatures. It MUST be signed with RSA.
ECDHE_RSA证书必须包含授权用于数字签名的RSA公钥。它必须用RSA签名。
Table 3: Server Certificate Types
表3：服务器证书类型
Structure of this message:
此消息的结构：
Identical to the TLS Certificate format.
与TLS证书格式相同。
Actions of the sender:
发件人的操作：
The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves; in particular, the public key MUST employ a named curve (not the same curve as an explicit curve) unless the client has indicated support for explicit curves of the appropriate type. If the client has used a Supported Point Formats Extension, both the server's public key point and (in the case of an explicit curve) the curve's base point MUST respect the client's choice of point formats. (A server that cannot satisfy these requirements MUST NOT choose an ECC cipher suite in its ServerHello message.)
服务器构造适当的证书链，并在证书消息中将其传递给客户端。如果客户端使用了受支持的椭圆曲线扩展，则服务器证书中的公钥必须尊重客户端对椭圆曲线的选择；特别是，公钥必须使用命名曲线（与显式曲线不同的曲线），除非客户机指示支持适当类型的显式曲线。如果客户端使用了受支持的点格式扩展，则服务器的公钥点和（在显式曲线的情况下）曲线的基点必须尊重客户端对点格式的选择。（不能满足这些要求的服务器不得在其ServerHello消息中选择ECC密码套件。）
Actions of the receiver:
接收方的行动：
The client validates the certificate chain, extracts the server's public key, and checks that the key type is appropriate for the negotiated key exchange algorithm. (A possible reason for a fatal handshake failure is that the client's capabilities for handling elliptic curves and point formats are exceeded; cf. Section 5.1.)
客户端验证证书链，提取服务器的公钥，并检查密钥类型是否适合协商密钥交换算法。（致命握手失败的一个可能原因是超出了客户端处理椭圆曲线和点格式的能力；参见第5.1节。）
When this message is sent:
发送此消息时：
This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and ECDH_anon key exchange algorithms.
此消息在使用ECDHE_ECDSA、ECDHE_RSA和ECDH_anon密钥交换算法时发送。
Meaning of this message:
此信息的含义：
This message is used to convey the server's ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client.
此消息用于将服务器的临时ECDH公钥（以及相应的椭圆曲线域参数）传递给客户端。
Structure of this message:
此消息的结构：
enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), reserved(248..255) } ECCurveType;
enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), reserved(248..255) } ECCurveType;
explicit_prime: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a prime field.
explicit_prime：表示椭圆曲线域参数被详细传输，底层有限域是prime域。
explicit_char2: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a characteristic-2 field.
explicit_char2：表示椭圆曲线域参数被详细传输，底层有限域是特征-2域。
named_curve: Indicates that a named curve is used. This option SHOULD be used when applicable.
命名曲线：表示使用了命名曲线。适用时应使用此选项。
Values 248 through 255 are reserved for private use.
值248到255保留供私人使用。
The ECCurveType name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
ECCurveType名称空间由IANA维护。有关如何添加新值分配的信息，请参见第8节。
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
} ECCurve;
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
} ECCurve;
a, b: These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI X9.62 [7].
a、 这些参数指定了椭圆曲线的系数。每个值包含ANSI X9.62[7]第4.3.3节中转换例程之后的字段元素的字节字符串表示。
struct {
opaque point <1..2^8-1>;
} ECPoint;
struct {
opaque point <1..2^8-1>;
} ECPoint;
point: This is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI X9.62 [7]. This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used.
点：这是ANSI X9.62[7]第4.3.6节中转换例程之后椭圆曲线点的字节字符串表示。此字节字符串可以表示未压缩或压缩格式的椭圆曲线点；如果使用此扩展，则它必须符合客户端通过支持的点格式扩展所请求的内容。
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic-2 field using a trinomial basis.
ec_基_三项式：表示使用三项式基表示特征-2字段。
ec_basis_pentanomial: Indicates representation of a characteristic-2 field using a pentanomial basis.
ec_基_五项式：表示使用五项式基表示特征-2字段。
struct {
ECCurveType curve_type;
select (curve_type) {
case explicit_prime:
opaque prime_p <1..2^8-1>;
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case explicit_char2:
uint16 m;
ECBasisType basis;
select (basis) {
case ec_trinomial:
opaque k <1..2^8-1>;
case ec_pentanomial:
opaque k1 <1..2^8-1>;
opaque k2 <1..2^8-1>;
opaque k3 <1..2^8-1>;
};
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
struct {
ECCurveType curve_type;
select (curve_type) {
case explicit_prime:
opaque prime_p <1..2^8-1>;
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case explicit_char2:
uint16 m;
ECBasisType basis;
select (basis) {
case ec_trinomial:
opaque k <1..2^8-1>;
case ec_pentanomial:
opaque k1 <1..2^8-1>;
opaque k2 <1..2^8-1>;
opaque k3 <1..2^8-1>;
};
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type: This identifies the type of the elliptic curve domain parameters.
curve_type：标识椭圆曲线域参数的类型。
prime_p: This is the odd prime defining the field Fp.
素数p：这是定义字段Fp的奇数素数。
curve: Specifies the coefficients a and b of the elliptic curve E.
曲线：指定椭圆曲线E的系数a和b。
base: Specifies the base point G on the elliptic curve.
基点：指定椭圆曲线上的基点G。
order: Specifies the order n of the base point.
顺序：指定基点的顺序n。
cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
represents the number of points on the elliptic curve E defined
over the field Fq (either Fp or F2^m).
cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
represents the number of points on the elliptic curve E defined
over the field Fq (either Fp or F2^m).
m: This is the degree of the characteristic-2 field F2^m.
m：这是特征-2字段F2^m的阶数。
k: The exponent k for the trinomial basis representation x^m + x^k +1.
k：三项式基表示x^m+x^k+1的指数k。
k1, k2, k3: The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
k1，k2，k3：五项式表示的指数x^m+x^k3+x^k2+x^k1+1（这样k3>k2>k1）。
namedcurve: Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve. Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02).
域名称：指定一组建议的椭圆曲线。NamedCurve的所有这些值都允许引用特定曲线。此处不允许使用NamedCurve值表示支持一类明确定义的曲线（它们仅在ClientHello扩展中允许）；这适用于任意_显式_素数_曲线（0xFF01）和任意_显式_char2_曲线（0xFF02）。
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params: Specifies the elliptic curve domain parameters associated with the ECDH public key.
curve_params：指定与ECDH公钥关联的椭圆曲线域参数。
public: The ephemeral ECDH public key.
public：临时ECDH公钥。
The ServerKeyExchange message is extended as follows.
ServerKeyExchange消息扩展如下。
enum { ec_diffie_hellman } KeyExchangeAlgorithm;
enum { ec_diffie_hellman } KeyExchangeAlgorithm;
ec_diffie_hellman: Indicates the ServerKeyExchange message contains an ECDH public key.
ec_diffie_hellman：表示ServerKeyExchange消息包含ECDH公钥。
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
params: Specifies the ECDH public key and associated domain parameters.
params：指定ECDH公钥和关联的域参数。
signed_params: A hash of the params, with the signature appropriate to that hash applied. The private key corresponding to the certified public key in the server's Certificate message is used for signing.
signed_params：参数的散列，并应用与该散列相应的签名。与服务器证书消息中的认证公钥相对应的私钥用于签名。
enum { ecdsa } SignatureAlgorithm;
enum { ecdsa } SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
} Signature;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash SHA(ClientHello.random + ServerHello.random + ServerKeyExchange.params);
ServerKeyExchange.signed_params.sha_hash sha（ClientHello.random+ServerHello.random+ServerKeyExchange.params）；
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon. These cases are defined in TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA signatures are generated and verified as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding [9] corresponding to the following ASN.1 notation [8].
注：签名算法对于ECDHE_rsa密钥交换算法为“rsa”，对于ECDH_anon为“匿名”。这些情况在TLS[2][3]中定义。签名算法是ECDHEU ecdsa的“ecdsa”。ECDSA签名按照第5.10节所述生成和验证，上述SHA_哈希模板中的SHA相应地表示除SHA-1之外的哈希算法。根据ANSI X9.62，ECDSA签名由一对整数r和s组成。数字签名元素被编码为不透明向量<0..2^16-1>，其内容是对应于以下ASN.1符号[8]的DER编码[9]。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Actions of the sender:
发件人的操作：
The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ServerKeyExchange message using the format defined above.
服务器根据IEEE 1363[6]中的ECKAS-DH1方案选择椭圆曲线域参数和与这些参数对应的临时ECDH公钥。它使用上面定义的格式在ServerKeyExchange消息中将此信息传递给客户端。
Actions of the receiver:
接收方的行动：
The client verifies the signature (when present) and retrieves the server's elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message. (A possible reason for a fatal handshake failure is that the client's capabilities for handling elliptic curves and point formats are exceeded; cf. Section 5.1.)
客户端验证签名（如果存在），并从ServerKeyExchange消息中检索服务器的椭圆曲线域参数和临时ECDH公钥。（致命握手失败的一个可能原因是超出了客户端处理椭圆曲线和点格式的能力；参见第5.1节。）
When this message is sent:
发送此消息时：
This message is sent when requesting client authentication.
此消息在请求客户端身份验证时发送。
Meaning of this message:
此信息的含义：
The server uses this message to suggest acceptable client authentication methods.
服务器使用此消息建议可接受的客户端身份验证方法。
Structure of this message:
此消息的结构：
The TLS CertificateRequest message is extended as follows.
TLS CertificateRequest消息扩展如下。
enum {
ecdsa_sign(64), rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(66), (255)
} ClientCertificateType;
enum {
ecdsa_sign(64), rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(66), (255)
} ClientCertificateType;
ecdsa_sign, etc. Indicates that the server would like to use the corresponding client authentication method specified in Section 3.
ecdsa_sign等表示服务器希望使用第3节中指定的相应客户端身份验证方法。
Actions of the sender:
发件人的操作：
The server decides which client authentication methods it would like to use, and conveys this information to the client using the format defined above.
服务器决定要使用哪些客户端身份验证方法，并使用上面定义的格式将此信息传递给客户端。
Actions of the receiver:
接收方的行动：
The client determines whether it has a suitable certificate for use with any of the requested methods and whether to proceed with client authentication.
客户机确定其是否具有与任何请求的方法一起使用的合适证书，以及是否继续进行客户机身份验证。
When this message is sent:
发送此消息时：
This message is sent in response to a CertificateRequest when a client has a suitable certificate and has decided to proceed with client authentication. (Note that if the server has used a Supported Point Formats Extension, a certificate can only be considered suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and ECDSA_fixed_ECDH authentication methods if the public key point specified in it respects the server's choice of point formats. If no Supported Point Formats Extension has been used, a certificate can only be considered suitable for use with these authentication methods if the point is represented in uncompressed point format.)
当客户端拥有合适的证书并决定继续进行客户端身份验证时，将发送此消息以响应CertificateRequest。（请注意，如果服务器使用了受支持的点格式扩展，则如果证书中指定的公钥点尊重服务器对点格式的选择，则只能将证书视为适合与ECDSA_签名、RSA_fixed_ECDH和ECDSA_fixed_ECDH身份验证方法一起使用。如果未使用受支持的点格式扩展，则只有当点以未压缩的点格式表示时，才能认为证书适合与这些身份验证方法一起使用。）
Meaning of this message:
此信息的含义：
This message is used to authentically convey the client's static public key to the server. The following table summarizes what client certificate types are appropriate for the ECC-based client authentication mechanisms described in Section 3. ECC public keys must be encoded in certificates as described in Section 5.9.
此消息用于将客户端的静态公钥真实地传递给服务器。下表总结了适用于第3节中描述的基于ECC的客户端身份验证机制的客户端证书类型。ECC公钥必须按照第5.9节所述在证书中进行编码。
NOTE: The client's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 4 apply only to the client's certificate (first in the chain).
注意：客户端的证书消息能够承载证书链。表4中提到的限制仅适用于客户的证书（链中的第一个）。
Client
Authentication Method Client Certificate Type
--------------------- -----------------------
Client
Authentication Method Client Certificate Type
--------------------- -----------------------
ECDSA_sign Certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
ECDSA_签名证书必须包含支持ECDSA的公钥，并使用ECDSA签名。
ECDSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with ECDSA.
ECDSA_fixed_ECDH证书必须在与服务器的长期ECDH密钥相同的椭圆曲线上包含支持ECDH的公钥。此证书必须使用ECDSA签名。
RSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with RSA.
RSA_fixed_ECDH证书必须在与服务器的长期ECDH密钥相同的椭圆曲线上包含支持ECDH的公钥。此证书必须使用RSA签名。
Table 4: Client Certificate Types
表4：客户端证书类型
Structure of this message:
此消息的结构：
Identical to the TLS client Certificate format.
与TLS客户端证书格式相同。
Actions of the sender:
发件人的操作：
The client constructs an appropriate certificate chain, and conveys it to the server in the Certificate message.
客户端构造适当的证书链，并在证书消息中将其传递给服务器。
Actions of the receiver:
接收方的行动：
The TLS server validates the certificate chain, extracts the client's public key, and checks that the key type is appropriate for the client authentication method.
TLS服务器验证证书链，提取客户端的公钥，并检查密钥类型是否适合客户端身份验证方法。
When this message is sent:
发送此消息时：
This message is sent in all key exchange algorithms. If client authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this message is empty. Otherwise, it contains the client's ephemeral ECDH public key.
此消息在所有密钥交换算法中发送。如果使用ECDSA_fixed_ECDH或RSA_fixed_ECDH的客户端身份验证，则此消息为空。否则，它包含客户端的临时ECDH公钥。
Meaning of the message:
信息的含义：
This message is used to convey ephemeral data relating to the key exchange belonging to the client (such as its ephemeral ECDH public key).
此消息用于传递与属于客户端的密钥交换有关的临时数据（例如其临时ECDH公钥）。
Structure of this message:
此消息的结构：
The TLS ClientKeyExchange message is extended as follows.
TLS ClientKeyExchange消息扩展如下。
enum { implicit, explicit } PublicValueEncoding;
enum { implicit, explicit } PublicValueEncoding;
implicit, explicit: For ECC cipher suites, this indicates whether the client's ECDH public key is in the client's certificate ("implicit") or is provided, as an ephemeral ECDH public key, in the ClientKeyExchange message ("explicit"). (This is "explicit" in ECC cipher suites except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.)
隐式、显式：对于ECC密码套件，这表示客户端的ECDH公钥是在客户端的证书中（“隐式”）还是作为临时ECDH公钥提供在ClientKeyExchange消息中（“显式”）。（这在ECC密码套件中是“明确的”，除非客户端使用ECDSA_fixed_ECDH或RSA_fixed_ECDH客户端身份验证机制。）
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in uncompressed or compressed format. Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used.
ecdh_Yc：以字节字符串ECPoint.point的形式包含客户端的临时ecdh公钥，ECPoint.point可以表示未压缩或压缩格式的椭圆曲线点。在这里，如果使用了此扩展，则格式必须符合服务器通过支持的点格式扩展请求的格式；如果未使用此扩展，则必须解压缩格式。
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
发件人的操作：
The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ClientKeyExchange message using the format defined above.
客户机根据IEEE 1363[6]中的ECKAS-DH1方案，选择与从服务器接收到的参数相对应的临时ECDH公钥。它使用上面定义的格式在ClientKeyExchange消息中将此信息传递给客户端。
Actions of the receiver:
接收方的行动：
The server retrieves the client's ephemeral ECDH public key from the ClientKeyExchange message and checks that it is on the same elliptic curve as the server's ECDH key.
服务器从ClientKeyExchange消息中检索客户端的临时ECDH公钥，并检查它是否与服务器的ECDH密钥位于同一椭圆曲线上。
When this message is sent:
发送此消息时：
This message is sent when the client sends a client certificate containing a public key usable for digital signatures, e.g., when the client is authenticated using the ECDSA_sign mechanism.
当客户端发送包含可用于数字签名的公钥的客户端证书时，例如，当客户端使用ECDSA_签名机制进行身份验证时，将发送此消息。
Meaning of the message:
信息的含义：
This message contains a signature that proves possession of the private key corresponding to the public key in the client's Certificate message.
此消息包含一个签名，该签名证明拥有与客户端证书消息中的公钥对应的私钥。
Structure of this message:
此消息的结构：
The TLS CertificateVerify message and the underlying Signature type are defined in [2] and [3], and the latter is extended here in Section 5.4. For the ecdsa case, the signature field in the CertificateVerify message contains an ECDSA signature computed over handshake messages exchanged so far, exactly similar to CertificateVerify with other signing algorithms in [2] and [3]:
TLS CertificateVerify消息和底层签名类型在[2]和[3]中定义，后者在第5.4节中进行了扩展。对于ecdsa情况，CertificateVerify消息中的签名字段包含通过迄今为止交换的握手消息计算的ecdsa签名，与[2]和[3]中的CertificateVerify与其他签名算法完全类似：
CertificateVerify.signature.sha_hash SHA(handshake_messages);
CertificateVerify.signature.sha_hash sha（握手消息）；
ECDSA signatures are computed as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding [9] corresponding to the following ASN.1 notation [8].
ECDSA签名按照第5.10节所述进行计算，上述SHA_散列模板中的SHA可相应表示除SHA-1之外的散列算法。根据ANSI X9.62，ECDSA签名由一对整数r和s组成。数字签名元素被编码为不透明向量<0..2^16-1>，其内容是对应于以下ASN.1符号[8]的DER编码[9]。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Actions of the sender:
发件人的操作：
The client computes its signature over all handshake messages sent or received starting at client hello and up to but not including this message. It uses the private key corresponding to its certified public key to compute the signature, which is conveyed in the format defined above.
客户机对从客户机hello开始到但不包括此消息发送或接收的所有握手消息计算其签名。它使用与其认证公钥对应的私钥来计算签名，签名以上面定义的格式传输。
Actions of the receiver:
接收方的行动：
The server extracts the client's signature from the CertificateVerify message, and verifies the signature using the public key it received in the client's Certificate message.
服务器从CertificateVerify消息中提取客户端的签名，并使用它在客户端的证书消息中接收到的公钥验证签名。
X.509 certificates containing ECC public keys or signed using ECDSA MUST comply with [14] or another RFC that replaces or extends it. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [7], FIPS 186-2 [11], and SEC 2 [13].
X.509包含ECC公钥或使用ECDSA签名的证书必须符合[14]或替代或扩展它的其他RFC。客户应使用ANSI X9.62[7]、FIPS 186-2[11]和SEC 2[13]中推荐的椭圆曲线域参数。
All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [6] using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated.
所有ECDH计算（包括参数和密钥生成以及共享秘密计算）均根据[6]使用ECKAS-DH1方案执行，身份映射作为密钥派生函数（KDF），因此premaster secret是表示为八位字节字符串的ECDH共享秘密椭圆曲线点的x坐标。请注意，FE2OSP（字段元素到八位字节字符串转换原语）输出的八位字节字符串（IEEE 1363术语中的Z）对于任何给定字段都具有恒定长度；不得截断此八位字节字符串中的前导零。
(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use the premaster secret for anything other than for computing the master secret. As of TLS 1.0 [2] and 1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a KDF; it is conceivable that future TLS versions or new TLS extensions introduced in the future may vary this computation.)
（注意，标识KDF的使用是一个技术性问题。完整的情况是ECDH与一个非平凡的KDF一起使用，因为TLS不直接将premaster secret用于计算主密钥以外的任何事情。从TLS 1.0[2]和1.1[3]，这意味着基于MD5和SHA-1的TLS PRF用作KDF；可以想象，将来引入的TLS版本或新的TLS扩展可能会改变此计算。）
All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. The default hash function is SHA-1 [10], and sha_size (see Sections 5.4 and 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public
所有ECDSA计算必须根据ANSI X9.62[7]或其后续标准执行。要签名/验证的数据是散列的，结果直接通过ECDSA算法运行，无需额外的散列。默认哈希函数为SHA-1[10]，SHA_大小（见第5.4节和第5.8节）为20。但是，如果证书包含EC公共密钥，则可以使用替代哈希函数，例如FIPS 180-2[10]中指定的新SHA哈希函数之一
key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)
密钥明确要求使用另一个哈希函数。（用于指定所需散列函数的机制尚未标准化，但本条款预期会实现此类标准化，并且无需更新此文档作为响应。例如，未来的PKIX RFC可能会选择在subjectPublicKeyInfo的参数字段中指定与公钥一起使用的散列函数。）
All RSA signatures must be generated and verified according to PKCS#1 [12] block type 1.
必须根据PKCS#1[12]块类型1生成和验证所有RSA签名。
The table below defines new ECC cipher suites that use the key exchange algorithms specified in Section 2.
下表定义了使用第2节中指定的密钥交换算法的新ECC密码套件。
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 }
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F }
CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 }
CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 }
CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 }
CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 }
CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 }
CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 }
CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 }
CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 }
Table 5: TLS ECC cipher suites
表5:TLS ECC密码套件
The key exchange method, cipher, and hash algorithm for each of these cipher suites are easily determined by examining the name. Ciphers (other than AES ciphers) and hash algorithms are defined in [2] and [3]. AES ciphers are defined in [19].
每个密码套件的密钥交换方法、密码和哈希算法都可以通过检查名称轻松确定。[2]和[3]中定义了密码（AES密码除外）和哈希算法。[19]中定义了AES密码。
Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
服务器实现应支持以下所有密码套件，客户端实现应至少支持其中一个：TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA和TLS_ECDHE_RSA_WITH_AES_128_cbu SHA。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
For TLS handshakes using ECC cipher suites, the security considerations in appendices D.2 and D.3 of [2] and [3] apply accordingly.
对于使用ECC密码套件的TLS握手，[2]和[3]附录D.2和D.3中的安全注意事项相应适用。
Security discussions specific to ECC can be found in [6] and [7]. One important issue that implementers and users must consider is elliptic curve selection. Guidance on selecting an appropriate elliptic curve size is given in Table 1.
[6]和[7]中有针对ECC的安全讨论。实现者和用户必须考虑的一个重要问题是椭圆曲线选择。表1给出了选择合适椭圆曲线尺寸的指南。
Beyond elliptic curve size, the main issue is elliptic curve structure. As a general principle, it is more conservative to use elliptic curves with as little algebraic structure as possible. Thus, random curves are more conservative than special curves such as Koblitz curves, and curves over F_p with p random are more conservative than curves over F_p with p of a special form (and curves over F_p with p random might be considered more conservative than curves over F_2^m as there is no choice between multiple fields of similar size for characteristic 2). Note, however, that algebraic structure can also lead to implementation efficiencies, and implementers and users may, therefore, need to balance conservatism against a need for efficiency. Concrete attacks are known against only very few special classes of curves, such as supersingular curves, and these classes are excluded from the ECC standards that this document references [6], [7].
除了椭圆曲线的大小，主要问题是椭圆曲线的结构。作为一般原则，使用代数结构尽可能少的椭圆曲线更为保守。因此，随机曲线比特殊曲线（如Koblitz曲线）更为保守，而F_p上带p随机的曲线比F_p上带p特殊形式的曲线更为保守（F_p上带有p random的曲线可能被认为比F_2^m上的曲线更保守，因为对于特征2，在多个大小相似的场之间没有选择）。但是，请注意，代数结构也可以提高实施效率，因此，实施者和用户可能需要平衡保守主义和效率需求。已知的具体攻击仅针对极少数特殊类别的曲线，如超奇异曲线，这些类别被排除在ECC标准之外本文件引用了[6]、[7]。
Another issue is the potential for catastrophic failures when a single elliptic curve is widely used. In this case, an attack on the elliptic curve might result in the compromise of a large number of keys. Again, this concern may need to be balanced against efficiency and interoperability improvements associated with widely-used curves. Substantial additional information on elliptic curve choice can be found in [5], [6], [7], and [11].
另一个问题是当一条椭圆曲线被广泛使用时，可能发生灾难性故障。在这种情况下，对椭圆曲线的攻击可能会导致大量密钥的泄露。同样，这一担忧可能需要与广泛使用的曲线相关的效率和互操作性改进相平衡。在[5]、[6]、[7]和[11]中可以找到关于椭圆曲线选择的大量附加信息。
Implementers and users must also consider whether they need forward secrecy. Forward secrecy refers to the property that session keys are not compromised if the static, certified keys belonging to the server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. Similarly, if the client is providing a static, certified key, ECDSA_sign client authentication provides forward secrecy protection in the event of client key compromise, while ECDSA_fixed_ECDH and RSA_fixed_ECDH do not. Thus, to obtain complete forward secrecy protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, with ECDSA_sign used for client authentication if necessary. Here again the security benefits of forward secrecy may need to be balanced against the improved efficiency offered by other options.
实现者和用户还必须考虑他们是否需要向前保密。前向保密性是指如果属于服务器和客户端的静态、经认证的密钥被泄露，会话密钥不会被泄露的属性。ECDHE_ECDSA和ECDHE_RSA密钥交换算法在服务器密钥泄露时提供前向保密保护，而ECDH_ECDSA和ECDH_RSA则不提供。类似地，如果客户机提供的是静态认证密钥，ECDSA_sign客户机身份验证在客户机密钥泄露时提供前向保密保护，而ECDSA_fixed_ECDH和RSA_fixed_ECDH则不提供。因此，为了获得完整的前向保密保护，必须使用ECDHE_ECDSA或ECDHE_RSA进行密钥交换，必要时使用ECDSA_签名进行客户端身份验证。在此，可能需要平衡前向保密的安全好处与其他选项提供的提高效率。
This document describes three new name spaces for use with the TLS protocol:
本文档介绍了三个用于TLS协议的新名称空间：
o NamedCurve (Section 5.1)
o 命名曲线（第5.1节）
o ECPointFormat (Section 5.1)
o ECPointFormat（第5.1节）
o ECCurveType (Section 5.4)
o ECCurveType（第5.4节）
For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use. Any additional assignments require IETF Consensus action [16].
对于每个名称空间，本文档定义了初始值分配，并定义了256个值（NamedCurve）或8个值（ECPointFormat和ECCurveType）的范围，保留供私人使用。任何额外的任务都需要IETF协商一致的行动[16]。
The authors wish to thank Bill Anderson and Tim Dierks.
作者要感谢比尔·安德森和蒂姆·迪克斯。
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[3] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[4] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://www.secg.org/>.
[5] SECG，“椭圆曲线密码术”，第1节，2000年<http://www.secg.org/>.
[6] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[6] IEEE，“公开密钥加密的标准规范”，IEEE 1363，2000。
[7] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998.
[7] ANSI，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.621998。
[8] International Telecommunication Union, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2002.
[8] 国际电信联盟，“信息技术——抽象语法符号一（ASN.1）：基本符号规范”，ITU-T建议X.680，2002年。
[9] International Telecommunication Union, "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, 2002.
[9] 国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范”，ITU-T建议X.690，2002年。
[10] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[10] NIST，“安全哈希标准”，FIPS 180-22002。
[11] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[11] NIST，“数字签名标准”，FIPS 186-22000。
[12] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", PKCS 1, November 1993.
[12] RSA实验室，“PKCS#1:RSA加密标准版本1.5”，PKCS 1，1993年11月。
[13] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 2000, <http://www.secg.org/>.
[13] SECG，“建议的椭圆曲线域参数”，第2节，2000年<http://www.secg.org/>.
[14] Polk, T., Housley, R., and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[14] Polk，T.，Housley，R.，和L.Bassham，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[15] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[15] Housley，R.，Polk，T.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[16] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
[17] Harper, G., Menezes, A., and S. Vanstone, "Public-Key Cryptosystems with Very Small Key Lengths", Advances in Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
[17] Harper，G.，Menezes，A.，和S.Vanstone，“密钥长度非常小的公钥密码系统”，密码学进展——EUROCRYPT'92，LNCS 6581993。
[18] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptology 14 (2001) 255-293, <http://www.cryptosavvy.com/>.
[18] Lenstra，A.和E.Verheul，“选择加密密钥大小”，密码学杂志14（2001）255-293<http://www.cryptosavvy.com/>.
[19] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[19] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
Appendix A. Equivalent Curves (Informative)
附录A.等效曲线（资料性）
All of the NIST curves [11] and several of the ANSI curves [7] are equivalent to curves listed in Section 5.1.1. In the following table, multiple names in one row represent aliases for the same curve.
所有NIST曲线[11]和几个ANSI曲线[7]与第5.1.1节中列出的曲线等效。在下表中，一行中的多个名称表示同一曲线的别名。
------------------------------------------
Curve names chosen by
different standards organizations
------------+---------------+-------------
SECG | ANSI X9.62 | NIST
------------+---------------+-------------
sect163k1 | | NIST K-163
sect163r1 | |
sect163r2 | | NIST B-163
sect193r1 | |
sect193r2 | |
sect233k1 | | NIST K-233
sect233r1 | | NIST B-233
sect239k1 | |
sect283k1 | | NIST K-283
sect283r1 | | NIST B-283
sect409k1 | | NIST K-409
sect409r1 | | NIST B-409
sect571k1 | | NIST K-571
sect571r1 | | NIST B-571
secp160k1 | |
secp160r1 | |
secp160r2 | |
secp192k1 | |
secp192r1 | prime192v1 | NIST P-192
secp224k1 | |
secp224r1 | | NIST P-224
secp256k1 | |
secp256r1 | prime256v1 | NIST P-256
secp384r1 | | NIST P-384
secp521r1 | | NIST P-521
------------+---------------+-------------
------------------------------------------
Curve names chosen by
different standards organizations
------------+---------------+-------------
SECG | ANSI X9.62 | NIST
------------+---------------+-------------
sect163k1 | | NIST K-163
sect163r1 | |
sect163r2 | | NIST B-163
sect193r1 | |
sect193r2 | |
sect233k1 | | NIST K-233
sect233r1 | | NIST B-233
sect239k1 | |
sect283k1 | | NIST K-283
sect283r1 | | NIST B-283
sect409k1 | | NIST K-409
sect409r1 | | NIST B-409
sect571k1 | | NIST K-571
sect571r1 | | NIST B-571
secp160k1 | |
secp160r1 | |
secp160r2 | |
secp192k1 | |
secp192r1 | prime192v1 | NIST P-192
secp224k1 | |
secp224r1 | | NIST P-224
secp256k1 | |
secp256r1 | prime256v1 | NIST P-256
secp384r1 | | NIST P-384
secp521r1 | | NIST P-521
------------+---------------+-------------
Table 6: Equivalent curves defined by SECG, ANSI, and NIST
表6:SECG、ANSI和NIST定义的等效曲线
Authors' Addresses
作者地址
Simon Blake-Wilson SafeNet Technologies BV Amstelveenseweg 88-90 1075 XJ, Amsterdam NL
Simon Blake Wilson SafeNet Technologies BV Amsteralvenseweg 88-90 1075 XJ，阿姆斯特丹NL
Phone: +31 653 899 836
EMail: sblakewilson@safenet-inc.com
Phone: +31 653 899 836
EMail: sblakewilson@safenet-inc.com
Nelson Bolyard Sun Microsystems Inc. 4170 Network Circle MS SCA17-201 Santa Clara, CA 95054 US
美国加利福尼亚州圣克拉拉市Nelson Bolyard Sun Microsystems Inc.4170 Network Circle MS SCA17-201，邮编95054
Phone: +1 408 930 1443
EMail: nelson@bolyard.com
Phone: +1 408 930 1443
EMail: nelson@bolyard.com
Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160 Menlo Park, CA 94025 US
Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160美国加利福尼亚州门罗公园94025
Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com
Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com
Chris Hawk Corriente Networks LLC 1563 Solano Ave., #484 Berkeley, CA 94707 US
Chris Hawk Corriente Networks LLC美国加利福尼亚州伯克利市索拉诺大道1563号，邮编94707
Phone: +1 510 527 0601
EMail: chris@corriente.net
Phone: +1 510 527 0601
EMail: chris@corriente.net
Bodo Moeller Ruhr-Uni Bochum Horst-Goertz-Institut, Lehrstuhl fuer Kommunikationssicherheit IC 4/139 44780 Bochum DE
波鸿霍斯特-戈尔茨学院博多·穆勒·鲁尔大学，Lehrstuhl fuer Comunikationssicherheit IC 4/139 44780波鸿德
Phone: +49 234 32 26795
EMail: bodo@openssl.org
Phone: +49 234 32 26795
EMail: bodo@openssl.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。