Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8422 Check Point
Obsoletes: 4492 S. Josefsson
Category: Standards Track SJD AB
ISSN: 2070-1721 M. Pegourie-Gonnard
ARM
August 2018
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8422 Check Point
Obsoletes: 4492 S. Josefsson
Category: Standards Track SJD AB
ISSN: 2070-1721 M. Pegourie-Gonnard
ARM
August 2018
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
用于传输层安全（TLS）1.2版及更早版本的椭圆曲线加密（ECC）密码套件
Abstract
摘要
This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.
本文档描述了用于传输层安全（TLS）协议的基于椭圆曲线密码（ECC）的密钥交换算法。特别是，它规定了在TLS握手中使用临时椭圆曲线Diffie-Hellman（ECDHE）密钥协议，以及使用椭圆曲线数字签名算法（ECDSA）和爱德华兹曲线数字签名算法（EdDSA）作为身份验证机制。
This document obsoletes RFC 4492.
本文件淘汰了RFC 4492。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8422.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8422.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Algorithms in Certificate Chains . . . . . . . . . . . . 7
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 8
3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 11
5.1.2. Supported Point Formats Extension . . . . . . . . . . 13
5.1.3. The signature_algorithms Extension and EdDSA . . . . 13
5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 14
5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 15
5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 16
5.4.1. Uncompressed Point Format for NIST Curves . . . . . . 19
5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 20
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 21
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 22
5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 23
5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 24
5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 24
5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 26
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 32
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Algorithms in Certificate Chains . . . . . . . . . . . . 7
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 8
3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 11
5.1.2. Supported Point Formats Extension . . . . . . . . . . 13
5.1.3. The signature_algorithms Extension and EdDSA . . . . 13
5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 14
5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 15
5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 16
5.4.1. Uncompressed Point Format for NIST Curves . . . . . . 19
5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 20
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 21
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 22
5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 23
5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 24
5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 24
5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 26
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 32
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
This document describes additions to TLS to support ECC that are applicable to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The use of ECC in TLS 1.3 is defined in [TLS1.3] and is explicitly out of scope for this document. In particular, this document defines:
本文档描述了TLS的新增内容，以支持适用于TLS版本1.0[RFC2246]、1.1[RFC4346]和1.2[RFC5246]的ECC。TLS 1.3中ECC的使用在[TLS1.3]中有定义，明确超出了本文件的范围。本文件特别规定：
o the use of the ECDHE key agreement scheme with ephemeral keys to establish the TLS premaster secret, and
o 使用带有临时密钥的ECDHE密钥协商方案来建立TLS premaster密钥，以及
o the use of ECDSA and EdDSA signatures for authentication of TLS peers.
o 使用ECDSA和EdDSA签名对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 ECC-based cipher suites and identifies a small subset of these as recommended for all implementations of this specification. Section 8 discusses security considerations. Section 9 describes IANA considerations for the name spaces created by this document's predecessor. Appendix B provides differences from [RFC4492], the document that this one replaces.
本文件的其余部分组织如下。第2节概述了基于ECC的TLS密钥交换算法。第3节介绍了ECC证书在客户端身份验证中的使用。第4节介绍了允许客户协商使用特定曲线和点格式的TLS扩展。第5节规定了基于ECC的握手所需的各种数据结构、它们在TLS消息中的编码以及这些消息的处理。第6节定义了基于ECC的密码套件，并确定了本规范所有实施建议的一小部分密码套件。第8节讨论了安全注意事项。第9节介绍了本文档的前身创建的名称空间的IANA注意事项。附录B提供了与[RFC4492]的不同之处，该文件取代了[RFC4492]。
Implementation of this specification requires familiarity with TLS, TLS extensions [RFC4366], and ECC.
本规范的实施要求熟悉TLS、TLS扩展[RFC4366]和ECC。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document defines three new ECC-based key exchange algorithms for TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS premaster secret, and they differ only in 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（ECDHE）来计算TLS premaster机密，它们的不同之处在于用于对它们进行身份验证的机制（如果有的话）。TLS主密钥从主密钥前的密钥派生以及随后生成的批量加密/MAC密钥和初始化向量独立于密钥交换算法，不受ECC引入的影响。
Table 1 summarizes the new key exchange algorithms. All of these key exchange algorithms provide forward secrecy if and only if fresh ephemeral keys are generated and used, and also destroyed after use.
表1总结了新的密钥交换算法。所有这些密钥交换算法都提供了前向保密性，当且仅当新的临时密钥被生成和使用，并且在使用后也被销毁。
+-------------+------------------------------------------------+
| Algorithm | Description |
+-------------+------------------------------------------------+
| ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. |
| ECDHE_RSA | Ephemeral ECDH with RSA signatures. |
| ECDH_anon | Anonymous ephemeral ECDH, no signatures. |
+-------------+------------------------------------------------+
+-------------+------------------------------------------------+
| Algorithm | Description |
+-------------+------------------------------------------------+
| ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. |
| ECDHE_RSA | Ephemeral ECDH with RSA signatures. |
| ECDH_anon | Anonymous ephemeral ECDH, no signatures. |
+-------------+------------------------------------------------+
Table 1: ECC Key Exchange Algorithms
表1:ECC密钥交换算法
These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, respectively.
这些密钥交换分别类似于DHE_DSS、DHE_RSA和DH_anon。
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 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证书，并轻松遵守受约束客户端的椭圆曲线首选项（请参见第4节）。然而，ECDHE_RSA服务器产生的计算成本高于传统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. Applications using TLS with this algorithm SHOULD provide authentication by other means.
匿名密钥交换算法不提供服务器或客户端的身份验证。与其他匿名TLS密钥交换一样，它也会受到中间人攻击。使用TLS和该算法的应用程序应通过其他方式提供身份验证。
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
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 1.2 Handshake
图1：完整TLS 1.2握手中的消息流
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 the 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中用“+”标识）的讨论推迟到第3节，将可选的ECC特定扩展（影响Hello消息）的讨论推迟到第4节。
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or EdDSA-capable public key.
在ECDHE_ECDSA中，服务器的证书必须包含支持ECDSA或EdDSA的公钥。
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 or EdDSA using the private key corresponding to the public key in the server's Certificate.
服务器发送其临时ECDH公钥和ServerKeyExchange消息中相应曲线的规范。必须使用与服务器证书中的公钥对应的私钥，使用ECDSA或EdDSA对这些参数进行签名。
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 (see Section 5.10) and use the resultant shared secret as the premaster secret.
客户机和服务器都执行ECDH操作（参见第5.10节），并将生成的共享密钥用作主密钥。
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 the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key.
此密钥交换算法与ECDHE_ECDSA相同，只是服务器的证书必须包含授权签名的RSA公钥，并且必须使用相应的RSA私钥计算ServerKeyExchange消息中的签名。
NOTE: Despite the name beginning with "ECDH_" (no E), the key used in ECDH_anon is ephemeral just like the key in ECDHE_RSA and ECDHE_ECDSA. The naming follows the example of DH_anon, where the key is also ephemeral but the name does not reflect it.
注意：尽管名称以“ECDH_”（no E）开头，但ECDH_anon中使用的密钥是短暂的，就像ECDHE_RSA和ECDHE_ECDSA中的密钥一样。命名遵循DH_anon的示例，其中键也是短暂的，但名称并不反映它。
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计算。
This specification does not impose restrictions on signature schemes used anywhere in the certificate chain. The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions, is lifted here as it had been in RFC 5246.
本规范不对证书链中任何位置使用的签名方案施加限制。本文件的前一版本要求签名匹配，但此限制源于前TLS版本，与RFC 5246中的限制一样在此处取消。
This document defines a client authentication mechanism named after the type of client certificate involved: ECDSA_sign. 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.
本文档定义了一种以涉及的客户端证书类型命名的客户端身份验证机制：ECDSA_sign。ECDSA_签名机制可用于第2节中描述的任何非匿名ECC密钥交换算法以及TLS中定义的其他非匿名（非ECC）密钥交换算法。
Note that client certificates with EdDSA public keys also use this mechanism.
请注意，具有EdDSA公钥的客户端证书也使用此机制。
The server can request ECC-based client authentication by including this certificate type in its CertificateRequest message. The client must check if it possesses a certificate appropriate for the method 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 MUST be sent as described in Section 2, and the CertificateVerify MUST 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 is 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- or EdDSA-capable public key.
要使用此身份验证机制，客户端必须拥有一个包含支持ECDSA或EdDSA的公钥的证书。
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消息中包含签名来证明拥有与认证密钥相对应的私钥。
Two 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 only support a limited number of curves or point formats. They follow the general approach outlined in [RFC4366]; 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.
本规范中定义了两个TLS扩展：（i）支持的椭圆曲线扩展和（ii）支持的点格式扩展。这些允许在握手开始新会话期间协商使用特定曲线和点格式（例如，分别为压缩和未压缩）。这些扩展尤其适用于可能仅支持有限数量的曲线或点格式的受约束客户端。它们遵循[RFC4366]中概述的一般方法；第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 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.
在ClientHello消息中提出ECC密码套件的TLS客户端应包括这些扩展。实现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 the previous three sections. The presentation language used here is the same as that used in TLS. 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.
本节规定了前三节中规定的基于ECC的密钥机制所使用的数据结构和计算。此处使用的表示语言与TLS中使用的表示语言相同。由于本规范扩展了TLS，因此这些描述应与TLS规范中的描述以及扩展TLS的任何其他描述合并。这意味着枚举类型可能不会指定所有可能的值，使用select（）子句选择多种格式的结构可能不会指示所有可能的情况。
This section specifies two TLS extensions that can be included with the ClientHello message as described in [RFC4366]: the Supported Elliptic Curves Extension and the Supported Point Formats Extension.
本节指定了两个TLS扩展，可包含在ClientHello消息中，如[RFC4366]中所述：支持的椭圆曲线扩展和支持的点格式扩展。
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 [RFC4366], and this specification adds two types to ExtensionType.
[RFC4366]中描述了TLS扩展的一般结构，该规范向ExtensionType添加了两种类型。
enum {
elliptic_curves(10),
ec_point_formats(11)
} ExtensionType;
enum {
elliptic_curves(10),
ec_point_formats(11)
} ExtensionType;
o 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 NamedCurveList. See Section 5.1.1 for details.
o 椭圆曲线（支持的椭圆曲线扩展）：表示客户端支持的椭圆曲线集。对于此扩展，不透明扩展_数据字段包含NamedCurveList。详见第5.1.1节。
o 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.
o 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 the ECDSA or EdDSA key in its certificate and for the ephemeral ECDH key in the ServerKeyExchange message. The server MUST consider the extensions in both cases.
注意：参与ECDHE_ECDSA密钥交换的服务器可能会对其证书中的ECDSA或EdDSA密钥以及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密码套件的使用。根据客户端提出并由服务器支持的其他密码套件，这可能会由于缺少通用密码套件而导致致命的握手失败警报。
RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "TLS Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS. Only three have seen much use. This specification is deprecating the rest (with numbers 1-22). This specification also deprecates the explicit
RFC 4492在NamedCurve注册表（现在重命名为“TLS支持的组”注册表，尽管下面的枚举仍然命名为NamedCurve）中定义了25条不同的曲线，以便在TLS中使用。只有三个有很大的用处。本规范不推荐其他规范（编号为1-22）。本规范还不推荐显式
curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves defined in [RFC7748]. The end result is as follows:
标识符为0xFF01和0xFF02的曲线。它还添加了[RFC7748]中定义的新曲线。最终结果如下：
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519(29), x448(30),
reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02),
(0xFFFF)
} NamedCurve;
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519(29), x448(30),
reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02),
(0xFFFF)
} NamedCurve;
Note that other specifications have since added other values to this enumeration. Some of those values are not curves at all, but finite field groups. See [RFC7919].
请注意，此后其他规范向该枚举添加了其他值。其中一些值根本不是曲线，而是有限域组。见[RFC7919]。
secp256r1, etc: Indicates support of the corresponding named curve or groups. The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 [SECG-SEC2]. These curves are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]. The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute of Standards and Technology. The curves x25519 and x448 are defined in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for private use.
secp256r1等：表示支持相应的命名曲线或组。命名曲线secp256r1、secp384r1和secp521r1在第2节[SECG-SEC2]中指定。ANSI X9.62[ANSI.X9-62.2005]和FIPS 186-4[FIPS.186-4]中也建议使用这些曲线。本文件其余部分将这三条曲线称为“NIST曲线”，因为它们最初是由国家标准与技术研究所标准化的。[RFC7748]中定义了曲线x25519和x448。值0xFE00到0xFEFF保留供私人使用。
The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this specification.
本文档的前身还支持显式定义的素数和char2曲线，但本规范不推荐使用这些曲线。
The NamedCurve name space (now titled "TLS Supported Groups") is maintained by IANA. See Section 9 for information on how new value assignments are added.
NamedCurve名称空间（现在标题为“TLS支持的组”）由IANA维护。有关如何添加新值分配的信息，请参见第9节。
struct {
NamedCurve named_curve_list<2..2^16-1>
} NamedCurveList;
struct {
NamedCurve named_curve_list<2..2^16-1>
} NamedCurveList;
Items in named_curve_list are ordered according to the client's preferences (favorite choice first).
命名_曲线_列表中的项目根据客户的首选项排序（首选项优先）。
As an example, a client that only supports secp256r1 (aka NIST P-256; value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) and prefers to use secp256r1 would include a TLS extension consisting of the following octets. Note that the first two octets indicate the extension type (Supported Elliptic Curves Extension):
例如，仅支持secp256r1（又名NIST P-256；值23=0x0017）和secp384r1（又名NIST P-384；值24=0x0018）且更愿意使用secp256r1的客户机将包括由以下八位字节组成的TLS扩展。请注意，前两个八位字节表示扩展类型（支持的椭圆曲线扩展）：
00 0A 00 06 00 04 00 17 00 18
00 0A 00 06 00 04 00 17 00 18
enum {
uncompressed (0),
deprecated (1..2),
reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
enum {
uncompressed (0),
deprecated (1..2),
reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Three point formats were included in the definition of ECPointFormat above. This specification deprecates all but the uncompressed point format. Implementations of this document MUST support the uncompressed format for all of their supported curves and MUST NOT support other formats for curves defined in this specification. For backwards compatibility purposes, the point format list extension MAY still be included and contain exactly one value: the uncompressed point format (0). RFC 4492 specified that if this extension is missing, it means that only the uncompressed point format is supported, so interoperability with implementations that support the uncompressed format should work with or without the extension.
上述ECPointFormat定义中包括三种点格式。此规范不推荐除未压缩点格式以外的所有格式。本文档的实现必须支持其所有受支持曲线的未压缩格式，并且不得支持本规范中定义的曲线的其他格式。出于向后兼容的目的，点格式列表扩展可能仍然包括在内，并且只包含一个值：未压缩点格式（0）。RFC 4492规定，如果缺少此扩展，则意味着只支持未压缩的点格式，因此与支持未压缩格式的实现的互操作性应在有或没有扩展的情况下工作。
If the client sends the extension and the extension does not contain the uncompressed point format, and the client has used the Supported Groups extension to indicate support for any of the curves defined in this specification, then the server MUST abort the handshake and return an illegal_parameter alert.
如果客户端发送扩展名，而扩展名不包含未压缩的点格式，并且客户端已使用Supported Groups扩展名表示支持本规范中定义的任何曲线，则服务器必须中止握手并返回非法的_参数警报。
The ECPointFormat name space (now titled "TLS EC Point Formats") is maintained by IANA. See Section 9 for information on how new value assignments are added.
ECPointFormat名称空间（现在标题为“TLS EC Point Formats”）由IANA维护。有关如何添加新值分配的信息，请参见第9节。
A client compliant with this specification that supports no other curves MUST send the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension):
符合本规范且不支持其他曲线的客户机必须发送以下八位字节：；请注意，前两个八位字节表示扩展类型（支持的点扩展格式）：
00 0B 00 02 01 00
00 0B 00 02 01 00
The signature_algorithms extension, defined in Section 7.4.1.4.1 of [RFC5246], advertises the combinations of signature algorithm and hash function that the client supports. The pure (non-prehashed) forms of EdDSA do not hash the data before signing it. For this reason, it does not make sense to combine them with a hash function in the extension.
[RFC5246]第7.4.1.4.1节中定义的签名算法扩展，宣传客户端支持的签名算法和哈希函数的组合。EdDSA的纯（非预灰化）形式在签名之前不会对数据进行散列。因此，将它们与扩展中的哈希函数相结合是没有意义的。
For bits-on-the-wire compatibility with TLS 1.3, we define a new dummy value in the "TLS HashAlgorithm" registry that we call "Intrinsic" (value 8), meaning that hashing is intrinsic to the signature algorithm.
为了与TLS 1.3兼容，我们在“TLS HashAlgorithm”注册表中定义了一个新的虚拟值，我们称之为“固有”（值8），这意味着哈希是签名算法固有的。
To represent ed25519 and ed448 in the signature_algorithms extension, the value shall be (8,7) and (8,8), respectively.
要在签名算法扩展中表示ed25519和ed448，值应分别为（8,7）和（8,8）。
This section specifies a TLS extension that can be included with the ServerHello message as described in [RFC4366], the Supported Point Formats Extension.
本节指定一个TLS扩展，该扩展可包含在ServerHello消息中，如[RFC4366]中所述，该扩展是受支持的点格式扩展。
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.
此扩展允许服务器枚举它可以解析的点格式（对于使用ECDHE_ECDSA、ECDHE_RSA或ECDH_anon密钥交换算法时将出现在其ServerKeyExchange消息中的曲线）。
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 ec_point_format_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. However, without extensions, this specification allows exactly one point format, so there is not really any opportunity for mismatches.
服务器支持的点格式扩展与客户端支持的点格式扩展具有相同的结构（参见第5.1.2节）。此处ec_point_format_列表中的项目根据服务器的首选项排序（首选项）。请注意，服务器可能包含在客户端列表中找不到的项目。但是，如果没有扩展，该规范只允许一点格式，因此实际上不存在任何不匹配的机会。
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 2 apply only to the server's certificate (first in the chain).
注意：服务器的证书消息能够承载证书链。表2中提到的限制仅适用于服务器的证书（链中的第一个）。
+-------------+-----------------------------------------------------+
| Algorithm | Server Certificate Type |
+-------------+-----------------------------------------------------+
| ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable |
| | public key. |
| ECDHE_RSA | Certificate MUST contain an RSA public key. |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| Algorithm | Server Certificate Type |
+-------------+-----------------------------------------------------+
| ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable |
| | public key. |
| ECDHE_RSA | Certificate MUST contain an RSA public key. |
+-------------+-----------------------------------------------------+
Table 2: Server Certificate Types
表2：服务器证书类型
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. A server that cannot satisfy this requirement 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公钥（以及相应的椭圆曲线域参数）传递给客户端。
The ECCurveType enum used to have values for explicit prime and for explicit char2 curves. Those values are now deprecated, so only one value remains:
ECCurveType枚举用于为显式素数和显式char2曲线提供值。这些值现在已弃用，因此只剩下一个值：
Structure of this message:
此消息的结构：
enum {
deprecated (1..2),
named_curve (3),
reserved(248..255)
} ECCurveType;
enum {
deprecated (1..2),
named_curve (3),
reserved(248..255)
} ECCurveType;
The value named_curve indicates that a named curve is used. This option is now the only remaining format.
名为_curve的值表示使用了命名曲线。此选项现在是唯一剩下的格式。
Values 248 through 255 are reserved for private use.
值248到255保留供私人使用。
The ECCurveType name space (now titled "TLS EC Curve Types") is maintained by IANA. See Section 9 for information on how new value assignments are added.
ECCurveType名称空间（现在标题为“TLS EC曲线类型”）由IANA维护。有关如何添加新值分配的信息，请参见第9节。
RFC 4492 had a specification for an ECCurve structure and an ECBasisType structure. Both of these are omitted now because they were only used with the now deprecated explicit curves.
RFC4492有一个ECCurve结构和ECBasisType结构的规范。这两种曲线现在都被省略了，因为它们只用于现在不推荐使用的显式曲线。
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.2005]. This byte string may represent an elliptic curve point in uncompressed, compressed, or hybrid format, but this specification deprecates all but the uncompressed format. For the NIST curves, the format is repeated in Section 5.4.1 for convenience. For the X25519 and X448 curves, the only valid representation is the one specified in [RFC7748], a 32- or 56-octet representation of the u value of the point. This structure MUST NOT be used with Ed25519 and Ed448 public keys.
点：这是[ANSI.X9-62.2005]第4.3.6节中转换例程之后椭圆曲线点的字节字符串表示。此字节字符串可以表示未压缩、压缩或混合格式的椭圆曲线点，但本规范不支持除未压缩格式以外的所有格式。对于NIST曲线，为方便起见，第5.4.1节重复了该格式。对于X25519和X448曲线，唯一有效的表示形式是[RFC7748]中指定的表示形式，即点u值的32或56八位字节表示形式。此结构不得与Ed25519和Ed448公钥一起使用。
struct {
ECCurveType curve_type;
select (curve_type) {
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
struct {
ECCurveType curve_type;
select (curve_type) {
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type: This identifies the type of the elliptic curve domain parameters.
curve_type：标识椭圆曲线域参数的类型。
namedCurve: Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a curve capable of Diffie-Hellman. With the deprecation of the explicit curves, this now includes all of the NamedCurve values.
namedCurve：指定一组建议的椭圆曲线域参数。NamedCurve的所有这些值都允许引用能够区分Hellman的曲线。随着显式曲线的弃用，它现在包括所有NamedCurve值。
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;
o ec_diffie_hellman: Indicates the ServerKeyExchange message contains an ECDH public key.
o 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;
o params: Specifies the ECDH public key and associated domain parameters.
o params：指定ECDH公钥和关联的域参数。
o 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.
o signed_params：参数的散列，并应用与该散列相应的签名。与服务器证书消息中的认证公钥相对应的私钥用于签名。
enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata
ClientHello.random + ServerHello.random +
ServerKeyExchange.params;
enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata
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. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.
注意：签名算法对于ECDHE_rsa密钥交换算法是“rsa”，对于ECDH_anon是“匿名”。这些情况在TLS中定义。签名算法是“ecdsa”或“eddsa”，用于ECDHE_ecdsa。
ECDSA signatures are generated and verified as described in Section 5.10. SHA, in the above template for sha_hash, 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 corresponding to the following ASN.1 notation.
ECDSA签名的生成和验证如第5.10节所述。在上述SHA_散列的模板中，SHA可以表示除SHA-1之外的散列算法。根据ANSI X9.62，ECDSA签名由一对整数r和s组成。数字签名元素被编码为不透明向量<0..2^16-1>，其内容是对应于以下ASN.1符号的DER编码。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
EdDSA signatures in both the protocol and in certificates that conform to [RFC8410] are generated and verified according to [RFC8032]. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which include the octet string output of the EdDSA signing algorithm.
协议和证书中符合[RFC8410]的EdDSA签名均根据[RFC8032]生成和验证。数字签名元素被编码为不透明向量<0..2^16-1>，其内容包括EdDSA签名算法的八进制字符串输出。
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 [IEEE.P1363]. It conveys this information to the client in the ServerKeyExchange message using the format defined above.
服务器根据IEEE 1363[IEEE.P1363]中的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节。）
The following represents the wire format for representing ECPoint in ServerKeyExchange records. The first octet of the representation indicates the form, which may be compressed, uncompressed, or hybrid. This specification supports only the uncompressed format for these curves. This is followed by the binary representation of the X value in "big-endian" or "network" format, followed by the binary representation of the Y value in "big-endian" or "network" format. There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters. For
以下是在ServerKeyExchange记录中表示ECPoint的连线格式。表示的第一个八位字节表示形式，可以是压缩的、未压缩的或混合的。本规范仅支持这些曲线的未压缩格式。然后是“big-endian”或“network”格式的X值的二进制表示，然后是“big-endian”或“network”格式的Y值的二进制表示。没有内部长度标记，因此每个数字表示法占用的八位字节数与曲线参数所暗示的八位字节数相同。对于
P-256 this means that each of X and Y use 32 octets, padded on the left by zeros if necessary. For P-384, they take 48 octets each, and for P-521, they take 66 octets each.
P-256这意味着X和Y每个使用32个八位字节，如果需要，在左边用零填充。对于P-384，它们每个有48个八位组，而对于P-521，它们每个有66个八位组。
Here's a more formal representation:
这里有一个更正式的表述：
enum {
uncompressed(4),
(255)
} PointConversionForm;
enum {
uncompressed(4),
(255)
} PointConversionForm;
struct {
PointConversionForm form;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
struct {
PointConversionForm form;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
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),
deprecated1(65), /* was rsa_fixed_ecdh */
deprecated2(66), /* was ecdsa_fixed_ecdh */
(255)
} ClientCertificateType;
enum {
ecdsa_sign(64),
deprecated1(65), /* was rsa_fixed_ecdh */
deprecated2(66), /* was ecdsa_fixed_ecdh */
(255)
} ClientCertificateType;
o ecdsa_sign: Indicates that the server would like to use the corresponding client authentication method specified in Section 3.
o ecdsa_sign：表示服务器希望使用第3节中指定的相应客户端身份验证方法。
Note that RFC 4492 also defined RSA and ECDSA certificates that included a fixed ECDH public key. These mechanisms saw very little implementation, so this specification is deprecating them.
请注意，RFC4492还定义了RSA和ECDSA证书，其中包括一个固定的ECDH公钥。这些机制几乎没有实现，因此本规范不推荐它们。
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 authentication method if the public key point specified in it is uncompressed, as that is the only point format still supported.
当客户端拥有合适的证书并决定继续进行客户端身份验证时，将发送此消息以响应CertificateRequest。（请注意，如果服务器使用了受支持的点格式扩展，则只有在证书中指定的公钥点未压缩的情况下，证书才能被视为适合与ECDSA_签名身份验证方法一起使用，因为这是唯一仍受支持的点格式。）。
Meaning of this message:
此信息的含义：
This message is used to authentically convey the client's static public key to the server. ECC public keys must be encoded in certificates as described in Section 5.9. The certificate MUST contain an ECDSA- or EdDSA-capable public key.
此消息用于将客户端的静态公钥真实地传递给服务器。ECC公钥必须按照第5.9节所述在证书中进行编码。证书必须包含支持ECDSA或EdDSA的公钥。
NOTE: The client's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned above apply only to the client's certificate (first in the chain).
注意：客户端的证书消息能够承载证书链。上述限制仅适用于客户的证书（链中的第一个）。
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. It contains the client's ephemeral ECDH public key.
此消息在所有密钥交换算法中发送。它包含客户端的临时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;
o 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"). The implicit encoding is deprecated and is retained here for backward compatibility only.
o 隐式、显式：对于ECC密码套件，这表示客户端的ECDH公钥是在客户端的证书中（“隐式”）还是作为临时ECDH公钥提供在ClientKeyExchange消息中（“显式”）。隐式编码已被弃用，保留在此处只是为了向后兼容。
struct {
ECPoint ecdh_Yc;
} ClientECDiffieHellmanPublic;
struct {
ECPoint ecdh_Yc;
} 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 format.
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. The format is the same as in Section 5.4.
客户机选择与从服务器接收到的参数相对应的临时ECDH公钥。格式与第5.4节相同。
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.
当客户端发送包含可用于数字签名的公钥的客户端证书时，将发送此消息。
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 the TLS base specifications, and the latter is extended here in Section 5.4. For the "ecdsa" and "eddsa" cases, the signature field in the CertificateVerify message contains an ECDSA or EdDSA (respectively) signature computed over handshake messages exchanged so far, exactly similar to CertificateVerify with other signing algorithms:
TLS CertificateVerify消息和底层签名类型在TLS基本规范中定义，后者在第5.4节中进行了扩展。对于“ecdsa”和“eddsa”情况，CertificateVerify消息中的签名字段包含通过迄今为止交换的握手消息计算的ecdsa或eddsa（分别）签名，与CertificateVerify与其他签名算法完全类似：
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.signature.rawdata
handshake_messages;
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.signature.rawdata
handshake_messages;
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 [X.690] corresponding to the following ASN.1 notation [X.680].
ECDSA签名按照第5.10节所述进行计算，上述SHA_散列模板中的SHA可相应表示除SHA-1之外的散列算法。根据ANSI X9.62，ECDSA签名由一对整数r和s组成。数字签名元素被编码为不透明向量<0..2^16-1>，其内容是对应于以下ASN.1符号[X.680]的DER编码[X.690]。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
EdDSA signatures are generated and verified according to [RFC8032]. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which include the octet string output of the EdDSA signing algorithm.
EdDSA签名根据[RFC8032]生成和验证。数字签名元素被编码为不透明向量<0..2^16-1>，其内容包括EdDSA签名算法的八进制字符串输出。
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 [RFC3279] or another RFC that replaces or extends it. X.509 certificates containing ECC public keys or signed using EdDSA MUST comply with [RFC8410]. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 [SECG-SEC2], or in [RFC8032].
X.509包含ECC公钥或使用ECDSA签名的证书必须符合[RFC3279]或替代或扩展它的其他RFC。X.509包含ECC公钥或使用EdDSA签名的证书必须符合[RFC8410]。客户应使用ANSI X9.62、FIPS 186-4和SEC 2[SECG-SEC2]或[RFC8032]中推荐的椭圆曲线域参数。
EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature algorithm, and Ed448 keys MUST use the ed448 signature algorithm. This document does not define use of Ed25519ph and Ed448ph keys with TLS. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used with ECDSA.
使用Ed25519算法的EdDSA密钥必须使用Ed25519签名算法，Ed448密钥必须使用Ed448签名算法。本文件未规定将Ed25519ph和Ed448ph密钥用于TLS。Ed25519、Ed25519ph、Ed448和Ed448ph密钥不得与ECDSA一起使用。
All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared secret calculation) are performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with the identity map as the 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 (Field
NIST曲线的所有ECDH计算（包括参数和密钥生成以及共享秘密计算）均根据[IEEE.P1363]使用ECKAS-DH1方案执行，其中身份映射作为密钥派生函数（KDF）因此，premaster secret是ECDH共享秘密椭圆曲线点的x坐标，表示为八位字符串。请注意，此八位组字符串（IEEE 1363术语中的Z）由FE2OSP（字段）输出
Element to Octet String Conversion Primitive), has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated.
元素到八位字节字符串转换原语），对于任何给定字段具有恒定长度；不得截断此八位字节字符串中的前导零。
(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. In TLS 1.0 and 1.1, this means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF) serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite, and 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和1.1中，这意味着基于MD5和SHA-1的TLS伪随机函数（PRF）用作KDF；在TLS 1.2中，KDF由ciphersuite确定，可以想象，将来引入的TLS版本或新的TLS扩展可能会改变此计算。）
An ECDHE key exchange using X25519 (curve x25519) goes as follows: (1) each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G); (2) parties exchange their public keys and compute a shared secret as x_S = X25519(d, x_peer); and (3), if either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarly, replacing X25519 with X448 and x25519 with x448. The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used.
使用X25519（曲线X25519）的ECDHE密钥交换如下所示：（1）各方随机统一地选择密钥d，并计算相应的公钥x=X25519（d，G）；（2） 各方交换其公钥并计算共享秘密，作为x_S=X25519（d，x_对等方）；和（3），如果任何一方获得所有零xs，则必须中止握手（根据X25519和X448的定义）。X448的ECDHE工作原理类似，将X25519替换为X448，将X25519替换为X448。派生的共享密钥直接用作premaster密钥，当使用带有X25519的ECDHE时，该密钥始终精确为32字节，当使用带有X448的ECDHE时，该密钥始终精确为56字节。
All ECDSA computations MUST be performed according to ANSI X9.62 or its successors. Data to be signed/verified is hashed, and the result runs directly through the ECDSA algorithm with no additional hashing. A secure hash function such as SHA-256, SHA-384, or SHA-512 from [FIPS.180-4] MUST be used.
所有ECDSA计算必须根据ANSI X9.62或其后续标准执行。要签名/验证的数据是散列的，结果直接通过ECDSA算法运行，无需额外的散列。必须使用[FIPS.180-4]中的安全哈希函数，如SHA-256、SHA-384或SHA-512。
All EdDSA computations MUST be performed according to [RFC8032] or its successors. Data to be signed/verified is run through the EdDSA algorithm with no hashing (EdDSA will internally run the data through the "prehash" function PH). The context parameter for Ed448 MUST be set to the empty string.
所有EdDSA计算必须按照[RFC8032]或其后续标准执行。待签名/验证的数据通过EdDSA算法运行，无需散列（EdDSA将通过“prehash”函数在内部运行数据）。Ed448的上下文参数必须设置为空字符串。
RFC 4492 anticipated the standardization of a mechanism for specifying the required hash function in the certificate, perhaps in the parameters field of the subjectPublicKeyInfo. Such standardization never took place, and as a result, SHA-1 is used in TLS 1.1 and earlier (except for EdDSA, which uses identity function). TLS 1.2 added a SignatureAndHashAlgorithm parameter to the DigitallySigned struct, thus allowing agility in choosing the signature hash. EdDSA signatures MUST have HashAlgorithm of 8 (Intrinsic).
RFC 4492预计将标准化一种机制，用于在证书中指定所需的哈希函数，可能在subjectPublicKeyInfo的参数字段中。这种标准化从未发生过，因此，在TLS 1.1和更早版本中使用了SHA-1（EdDSA除外，它使用标识功能）。TLS 1.2在DigitallySigned结构中添加了SignatureAndHashAlgorithm参数，从而允许灵活选择签名散列。EdDSA签名的哈希算法必须为8（固有）。
All RSA signatures must be generated and verified according to Section 7.2 of [RFC8017].
必须根据[RFC8017]第7.2节生成并验证所有RSA签名。
With the NIST curves, each party MUST validate the public key sent by its peer in the ClientKeyExchange and ServerKeyExchange messages. A receiving party MUST check that the x and y parameters from the peer's public value satisfy the curve equation, y^2 = x^3 + ax + b mod p. See Section 2.3 of [Menezes] for details. Failing to do so allows attackers to gain information about the private key to the point that they may recover the entire private key in a few requests if that key is not really ephemeral.
使用NIST曲线，各方必须验证其对等方在ClientKeyExchange和ServerKeyExchange消息中发送的公钥。接收方必须检查对等方公共值的x和y参数是否满足曲线方程y^2=x^3+ax+b mod p。详情见[Menezes]第2.3节。如果不这样做，攻击者就可以获得有关私钥的信息，如果该私钥不是真正短暂的，他们可以在几个请求中恢复整个私钥。
With X25519 and X448, a receiving party MUST check whether the computed premaster secret is the all-zero value and abort the handshake if so, as described in Section 6 of [RFC7748].
对于X25519和X448，接收方必须检查计算的premaster secret是否为全零值，如果是，则中止握手，如[RFC7748]第6节所述。
Ed25519 and Ed448 internally do public key validation as part of signature verification.
Ed25519和Ed448在内部进行公钥验证，作为签名验证的一部分。
The table below defines ECC cipher suites that use the key exchange algorithms specified in Section 2.
下表定义了使用第2节规定的密钥交换算法的ECC密码套件。
+-----------------------------------------+----------------+
| CipherSuite | Identifier |
+-----------------------------------------+----------------+
| TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } |
| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } |
| | |
| TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } |
| | |
| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } |
+-----------------------------------------+----------------+
+-----------------------------------------+----------------+
| CipherSuite | Identifier |
+-----------------------------------------+----------------+
| TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } |
| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } |
| | |
| TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } |
| | |
| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } |
+-----------------------------------------+----------------+
Table 3: TLS ECC Cipher Suites
表3: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 [RFC2246] and [RFC4346]. AES ciphers are defined in [RFC5246], and AES-GCM ciphersuites are in [RFC5289].
每个密码套件的密钥交换方法、密码和哈希算法都可以通过检查名称轻松确定。[RFC2246]和[RFC4346]中定义了密码（AES密码除外）和哈希算法。AES密码在[RFC5246]中定义，AES-GCM密码套件在[RFC5289]中定义。
Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them:
服务器实现应支持以下所有密码套件，客户端实现应至少支持其中一个：
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_与_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_RSA_与_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_ECDSA_与_AES_128_GCM_SHA256
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_与_AES_128_CBC_SHA
Both ECDHE and ECDSA with the NIST curves are widely implemented and supported in all major browsers and all widely used TLS libraries. ECDHE with Curve25519 is by now implemented in several browsers and several TLS libraries including OpenSSL. Curve448 and EdDSA have working interoperable implementations, but they are not yet as widely deployed.
具有NIST曲线的ECDHE和ECDSA在所有主要浏览器和所有广泛使用的TLS库中都得到广泛实施和支持。带有Curve25519的ECDHE现已在多个浏览器和多个TLS库（包括OpenSSL）中实现。Curve448和EdDSA具有可互操作的工作实现，但尚未广泛部署。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
For TLS handshakes using ECC cipher suites, the security considerations in Appendix D of each of the three TLS base documents apply accordingly.
对于使用ECC密码套件的TLS握手，三个TLS基础文档附录D中的安全注意事项相应适用。
Security discussions specific to ECC can be found in [IEEE.P1363] and [ANSI.X9-62.2005]. 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. Security considerations specific to X25519 and X448 are discussed in Section 7 of [RFC7748].
有关ECC的安全性讨论，请参见[IEEE.P1363]和[ANSI.X9-62.2005]。实现者和用户必须考虑的一个重要问题是椭圆曲线选择。表1给出了选择合适椭圆曲线尺寸的指南。[RFC7748]第7节讨论了X25519和X448特定的安全注意事项。
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
除了椭圆曲线的大小，主要问题是椭圆曲线的结构。作为一般原则，使用代数结构尽可能少的椭圆曲线更为保守。因此，随机曲线比特殊曲线（如Koblitz曲线）更为保守，而F_p上带有p random的曲线比F_p上带有特殊形式p的曲线更为保守，并且
curves over F_p with p random are considered more conservative than curves over F_2^m as there is no choice between multiple fields of similar size for characteristic 2.
与F_2^m上的曲线相比，具有p随机性的F_p上的曲线被认为更为保守，因为对于特征2，在多个大小相似的场之间没有选择。
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 [IEEE.P1363], [ANSI.X9-62.2005], and [FIPS.186-4].
另一个问题是当一条椭圆曲线被广泛使用时，可能发生灾难性故障。在这种情况下，对椭圆曲线的攻击可能会导致大量密钥的泄露。同样，这一担忧可能需要与广泛使用的曲线相关的效率和互操作性改进相平衡。在[IEEE.P1363]、[ANSI.X9-62.2005]和[FIPS.186-4]中可以找到关于椭圆曲线选择的大量附加信息。
The Introduction of [RFC8032] lists the security, performance, and operational advantages of EdDSA signatures over ECDSA signatures using the NIST curves.
[RFC8032]的介绍列出了EdDSA签名相对于使用NIST曲线的ECDSA签名的安全性、性能和操作优势。
All of the key exchange algorithms defined in this document provide forward secrecy. Some of the deprecated key exchange algorithms do not.
本文中定义的所有密钥交换算法都提供了前向保密性。有些不推荐使用的密钥交换算法没有。
[RFC4492], the predecessor of this document, defined the IANA registries for the following:
本文件的前身[RFC4492]定义了IANA注册中心的以下内容：
o Supported Groups (Section 5.1)
o 受支持群体（第5.1节）
o EC Point Format (Section 5.1)
o EC点格式（第5.1节）
o EC Curve Type (Section 5.4)
o EC曲线类型（第5.4节）
IANA has prepended "TLS" to the names of these three registries.
IANA在这三个注册中心的名称前加了“TLS”。
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. The policy for any additional assignments is "Specification Required". (RFC 4492 required IETF review.)
对于每个名称空间，本文档定义了初始值分配，并定义了256个值（NamedCurve）或8个值（ECPointFormat和ECCurveType）的范围，保留供私人使用。任何额外任务的政策是“要求规范”。（RFC 4492需要IETF审查。）
All existing entries in the "ExtensionType Values", "TLS ClientCertificateType Identifiers", "TLS Cipher Suites", "TLS Supported Groups", "TLS EC Point Format", and "TLS EC Curve Type" registries that referred to RFC 4492 have been updated to refer to this document.
已更新“ExtensionType值”、“TLS ClientCertificateType标识符”、“TLS密码套件”、“TLS支持的组”、“TLS EC点格式”和“TLS EC曲线类型”注册表中引用RFC 4492的所有现有条目，以引用本文档。
IANA has assigned the value 29 to x25519 and the value 30 to x448 in the "TLS Supported Groups" registry.
IANA已在“TLS支持的组”注册表中将值29分配给x25519，将值30分配给x448。
IANA has assigned two values in the "TLS SignatureAlgorithm" registry for ed25519 (7) and ed448 (8) with this document as reference. This keeps compatibility with TLS 1.3.
IANA在“TLS SignatureAlgorithm”注册表中为ed25519（7）和ed448（8）分配了两个值，并将本文件作为参考。这保持了与TLS 1.3的兼容性。
IANA has assigned one value from the "TLS HashAlgorithm" registry for Intrinsic (8) with DTLS-OK set to true (Y) and this document as reference. This keeps compatibility with TLS 1.3.
IANA已从“TLS HashAlgorithm”注册表中为内在（8）分配了一个值，DTLS-OK设置为true（Y），本文档作为参考。这保持了与TLS 1.3的兼容性。
[ANSI.X9-62.2005] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.
[ANSI.X9-62.2005]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62，2005年11月。
[FIPS.186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS.186-4]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-4，DOI 10.6028/NIST.FIPS.186-42013年7月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，DOI 10.17487/RFC2246，1999年1月<https://www.rfc-editor.org/info/rfc2246>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，DOI 10.17487/RFC3279，2002年4月<https://www.rfc-editor.org/info/rfc3279>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，DOI 10.17487/RFC4346，2006年4月<https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，DOI 10.17487/RFC4366，2006年4月<https://www.rfc-editor.org/info/rfc4366>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <https://www.rfc-editor.org/info/rfc5289>.
[RFC5289]Rescorla，E.“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，DOI 10.17487/RFC5289，2008年8月<https://www.rfc-editor.org/info/rfc5289>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<https://www.rfc-editor.org/info/rfc7748>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8410]Josefsson，S.和J.Schaad，“用于互联网X.509公钥基础设施的Ed25519、Ed448、X25519和X448的算法标识符”，RFC 8410，DOI 10.17487/RFC8410，2018年8月<https://www.rfc-editor.org/info/rfc8410>.
[SECG-SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography 2 (SEC 2), Version 2.0, January 2010, <http://www.secg.org/sec2-v2.pdf>.
[SECG-SEC2]Certicom Research，“第2节：建议的椭圆曲线域参数”，高效密码标准2（第2节），版本2.0，2010年1月<http://www.secg.org/sec2-v2.pdf>.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015.
[X.680]ITU-T，“抽象语法符号1（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC 8824-12015年8月。
[X.690] ITU-T, "Information technology-ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015.
[X.690]ITU-T，“信息技术ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-1，2015年8月。
[FIPS.180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS.180-4]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[IEEE.P1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE Std P1363, <http://ieeexplore.ieee.org/document/891000/>.
[IEEE.P1363]IEEE，“公钥加密的标准规范”，IEEE标准P1363<http://ieeexplore.ieee.org/document/891000/>.
[Menezes] Menezes, A. and B. Ustaoglu, "On reusing ephemeral keys in Diffie-Hellman key agreement protocols", International Journal of Applied Cryptography, Vol. 2, Issue 2, DOI 10.1504/IJACT.2010.038308, January 2010.
[Menezes]Menezes，A.和B.Ustaoglu，“关于在Diffie-Hellman密钥协议协议中重用临时密钥”，国际应用密码学杂志，第2卷，第2期，DOI 10.1504/IJACT.2010.038308，2010年1月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <https://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<https://www.rfc-editor.org/info/rfc4492>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919]Gillmor，D.“传输层安全（TLS）的协商有限域Diffie-Hellman瞬时参数”，RFC 7919，DOI 10.17487/RFC7919，2016年8月<https://www.rfc-editor.org/info/rfc7919>.
[TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-28, March 2018.
[TLS1.3]Rescorla，E.，“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-tls13-28，2018年3月。
Appendix A. Equivalent Curves (Informative)
附录A.等效曲线（资料性）
All of the NIST curves [FIPS.186-4] and several of the ANSI curves [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. The following table displays the curve names chosen by different standards organizations; multiple names in one row represent aliases for the same curve.
所有NIST曲线[FIPS.186-4]和几个ANSI曲线[ANSI.X9-62.2005]与第5.1.1节中列出的曲线等效。下表显示了不同标准组织选择的曲线名称；一行中的多个名称表示同一曲线的别名。
+-----------+------------+------------+
| 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 |
+-----------+------------+------------+
+-----------+------------+------------+
| 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 4: Equivalent Curves Defined by SECG, ANSI, and NIST
表4：SECG、ANSI和NIST定义的等效曲线
o Renamed EllipticCurveList to NamedCurveList.
o 将EllipticCurveList重命名为NamedCurveList。
o Added TLS 1.2.
o 增加了TLS 1.2。
o Merged errata.
o 合并勘误表。
o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA
o 删除了ECDH密钥交换算法：ECDH_RSA和ECDH_ECDSA
o Deprecated a bunch of ciphersuites:
o 不推荐使用一组密码套件：
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_与_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_与_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_与_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_与_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_与_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_与_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_与_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_与CBC_SHA_3DES_EDE_
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_与_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_与_AES_256_CBC_SHA
All the other RC4 ciphersuites
所有其他RC4密码套件
o Removed unused curves and all but the uncompressed point format.
o 删除了未使用的曲线和所有未压缩的点格式。
o Added X25519 and X448.
o 增加了X25519和X448。
o Deprecated explicit curves.
o 不推荐使用的显式曲线。
o Removed restriction on signature algorithm in certificate.
o 删除了对证书中签名算法的限制。
Acknowledgements
致谢
Most of the text in this document is taken from [RFC4492], the predecessor of this document. The authors of that document were:
本文件中的大部分文本取自本文件的前身[RFC4492]。该文件的作者是：
o Simon Blake-Wilson o Nelson Bolyard o Vipul Gupta o Chris Hawk o Bodo Moeller
o 西蒙·布莱克·威尔逊、纳尔逊·博尔亚德、维普尔·古普塔、克里斯·霍克、博多·默勒
In the predecessor document, the authors acknowledged the contributions of Bill Anderson and Tim Dierks.
在前一份文件中，作者感谢比尔·安德森和蒂姆·迪克斯的贡献。
The authors would like to thank Nikos Mavrogiannopoulos, Martin Thomson, and Tanja Lange for contributions to this document.
作者要感谢Nikos Mavrogiannopoulos、Martin Thomson和Tanja Lange对本文件的贡献。
Authors' Addresses
作者地址
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 6789735 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司6789735
Email: ynir.ietf@gmail.com
Email: ynir.ietf@gmail.com
Simon Josefsson SJD AB
西蒙·约瑟夫森SJD AB
Email: simon@josefsson.org
Email: simon@josefsson.org
Manuel Pegourie-Gonnard ARM
Manuel Pegourie Gonnard手臂
Email: mpg@elzevir.fr
Email: mpg@elzevir.fr