RFC 4492
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) 💖
okay bestie, so this one is an RFC from May 2006 that's basically the ECC glow-up for TLS 🎀 It was written by S. Blake-Wilson (SafeNet), N. Bolyard (Sun Microsystems), V. Gupta (Sun Labs), C. Hawk (Corriente), and B. Moeller (Ruhr-Uni Bochum), under the Network Working Group, and it's Request for Comments 4492. Its category is Informational, so it's providing info for the Internet community, not a formal standard. The header doesn't list anything it obsoletes or updates. Let's go! 🦋
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).
Abstract 🌸
This doc describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol 🔐 Specifically, it covers using Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake, plus the Elliptic Curve Digital Signature Algorithm (ECDSA) as a brand new authentication mechanism. Main character energy, literally 👑
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) ......................321. Introduction ✨
okay so ECC is emerging as a seriously attractive public-key cryptosystem, especially for mobile (i.e., wireless) environments 📱 Compared to the currently prevalent cryptosystems, like RSA, ECC offers equivalent security with smaller key sizes 🧠 This is illustrated in the table below, which is based on [18] and gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems, based on the best-known algorithms for attacking them.
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)Smaller key sizes lead to savings in power, memory, bandwidth, and computational cost. That's why ECC is giving so much iconic energy for constrained environments 🦋
This document adds ECC support to TLS, and it applies to both TLS Version 1.0 [2] and TLS Version 1.1 [3] 💖 Specifically, it defines:
- 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
- the use of fixed-ECDH certificates and ECDSA for authentication of TLS peers.
Here's the tour of the rest of the doc 🗺️ Section 2 gives an overview of the ECC-based key exchange algorithms for TLS. Section 3 covers using ECC certificates for client authentication. Section 4 has the TLS extensions that let a client negotiate specific curves and point formats. Section 5 specifies the data structures needed for an ECC-based handshake, how they're encoded in TLS messages, and how those messages get processed. Section 6 defines the new ECC-based cipher suites and names a small subset of them as recommended for all implementations of this specification. Section 7 discusses security considerations. Section 8 covers IANA considerations for the name spaces this document creates. Section 9 has the acknowledgements.
After that come the normative and informative references, the authors' contact info, and the statements on intellectual property rights and copyrights 📜
To implement this spec, you need to be familiar with TLS [2][3], TLS extensions [4], and 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] 🎀
2. Key Exchange Algorithms 🔐
This document introduces five new ECC-based key exchange algorithms for TLS. They all use ECDH to compute the TLS premaster secret. The only differences between them are the lifetime of the 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 later generation of bulk encryption/MAC keys and initialization vectors, doesn't depend on the key exchange algorithm and isn't affected by adding ECC.
The table below sums up the new key exchange algorithms. They mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and [3]), respectively 🦋
Key
Exchange
Algorithm Description
--------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDH_RSA Fixed ECDH with RSA-signed certificates.
ECDHE_RSA Ephemeral ECDH with RSA signatures.
ECDH_anon Anonymous ECDH, no signatures.
Table 2: ECC Key Exchange AlgorithmsECDHE_ECDSA and ECDHE_RSA both 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). The catch is that the computational cost for a server is higher with ECDHE_RSA than with the traditional RSA key exchange, which doesn't provide forward secrecy 💀
ECDH_RSA means a server has to get an ECC certificate, but the certificate issuer can still use an existing RSA key for signing 🙌 That means no need to update the keys of trusted certification authorities accepted by TLS clients. ECDH_ECDSA needs ECC keys for the server and for the certification authority too, and it's best suited for constrained devices that can't support RSA 🧚
⚠️ The anonymous key exchange algorithm does not provide authentication of the server or the client. Like other anonymous TLS key exchanges, it's subject to man-in-the-middle attacks. Implementations of this algorithm SHOULD provide authentication by other means.
Also, there's no structural difference between ECDH and ECDSA keys 🌈 A certificate issuer may use the X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations [15]. This document calls an ECC key ECDH-capable if its use in ECDH is permitted. ECDSA-capable is defined similarly.
Here's the message flow for a full handshake, and it's giving very organized vibes 📊
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 handshakeFigure 1 shows every message involved in the TLS key establishment protocol (aka full handshake) 💜 Adding ECC only directly affects the ClientHello, the ServerHello, the server's Certificate message, the ServerKeyExchange, the ClientKeyExchange, the CertificateRequest, the client's Certificate message, and the CertificateVerify. Next up, we go through each ECC key exchange algorithm in more detail, covering the content and processing of these messages. To keep things easy to follow, we save client authentication and its messages (marked with a + in Figure 1) for Section 3, and the optional ECC-specific extensions (which affect the Hello messages) for Section 4 🌸
2.1. ECDH_ECDSA 💖
okay so for ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA 🔐✨
a ServerKeyExchange MUST NOT be sent 🙅♀️ bc the server's certificate already has all the keying info the client needs to get to the premaster secret. it's giving self-sufficient cert 💅
the client makes 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 🦋 the exception is when the client auth algorithm is ECDSA_fixed_ECDH or RSA_fixed_ECDH, and then the changes from Section 3.2 or Section 3.3 apply instead 🫶
both client and server do an ECDH operation and use the shared secret they get as the premaster secret 🌈 all the ECDH math follows Section 5.10, no cap 🤓
2.2. ECDHE_ECDSA 🌸
for ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA 🔐
the server sends its ephemeral ECDH public key, plus a description of the matching curve, in the ServerKeyExchange message 🧚 those parameters MUST be signed with ECDSA, using the private key that goes with the public key in the server's Certificate 🔏 very important, don't skip this one bestie 😭
the client makes an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message 💜
both client and server do an ECDH operation (Section 5.10) and use the shared secret as the premaster secret ✨
2.3. ECDH_RSA 🍓
this one is basically ECDH_ECDSA, just with a twist: the server's certificate MUST be signed with RSA instead of ECDSA 💀 same vibe, different signature 🎀
2.4. ECDHE_RSA 🌈
ECDHE_RSA is the same as ECDHE_ECDSA, except the server's certificate MUST contain an RSA public key that's authorized for signing 🔑 and the signature in the ServerKeyExchange message has to be computed with the matching RSA private key 🔥 the server certificate MUST be signed with RSA too, so RSA is the main character here 👑
2.5. ECDH_anon 🙈
in ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent 🚫 no certs, no vibes, just ECDH 😌
the server MUST send an ephemeral ECDH public key and a description of the matching curve in the ServerKeyExchange message 🧚 those parameters MUST NOT be signed 🙃
the client makes an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message 🦋
both client and server do an ECDH operation and use the shared secret as the premaster secret, and all the ECDH calculations follow Section 5.10 ✨
Heads up, this next bit is a lil long but it's important 📝
note that ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA all need the server's certificate signed with one specific signature scheme. this spec, though, follows the same pattern as DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3], so it does NOT put restrictions on the signature schemes used anywhere else in the certificate chain 🧐 (ngl, those restrictions would often be useful, and CAs are expected to take that into account when they sign stuff. but they're not strictly required in general. even if a client can't fully validate a chain, it might still validate the server's cert by trusting a CA whose cert shows up as one of the intermediate certs in the chain 🌸)
3. Client Authentication 🔐
this doc defines three brand-new client auth mechanisms, each named after the kind of client cert involved: ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH 🎀 ECDSA_sign works with any of the non-anonymous ECC key exchange algorithms from Section 2, and also with the other non-anonymous (non-ECC) key exchange algorithms defined in TLS [2][3] ✨ ECDSA_fixed_ECDH and RSA_fixed_ECDH work with ECDH_ECDSA and ECDH_RSA. using them with ECDHE_ECDSA or ECDHE_RSA is prohibited 🙅♀️ because a long-term ECDH client key would wreck the forward secrecy property of those algorithms 😭
the server can ask for ECC-based client auth by putting one or more of these cert types in its CertificateRequest message 📨 it must not include any cert types that are prohibited for the negotiated key exchange algorithm 🚫 and the client must check whether it has a cert that matches any of the methods the server suggested, AND whether it's willing to use that cert for auth 🧐
if those conditions aren't met, the client should send a client Certificate message with no certificates in it 📭 in that case the ClientKeyExchange should be sent as described in Section 2, and the CertificateVerify should not be sent 🙅♀️ if the server requires client auth, it may respond with a fatal handshake failure alert 💀
if the client does have an appropriate cert and is willing to use it for auth, it must send that cert in the client's Certificate message (as per Section 5.6) and prove it has the private key for the certified key 🔑 how you figure out which cert is appropriate and how you prove possession is different for each auth mechanism, and it's described below 🦋
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 🌈
3.1. ECDSA_sign 💅
to use this auth mechanism, the client MUST possess a certificate containing an ECDSA-capable public key that's signed with ECDSA 🔐
the client proves it has the private key for the certified key by including a signature in the CertificateVerify message, as described in Section 5.8 ✨
3.2. ECDSA_fixed_ECDH 🌸
to use this auth mechanism, the client MUST possess a certificate containing an ECDH-capable public key, and that cert MUST be signed with ECDSA 🔏 also, the client's ECDH key MUST be on the same elliptic curve as the server's long-term (certified) ECDH key 🧚 this might limit the mechanism to closed environments 🏰 if the client has an ECC key on a different curve, it would have to auth with either ECDSA_sign or a non-ECC mechanism (like RSA) 🌈 using fixed ECDH for both servers and clients is computationally more efficient than mechanisms that provide forward secrecy ⚡
when using this auth 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 because the client's ECDH public key, which the server needs to compute the premaster secret, is already inside the client's certificate 📜 the client being able to arrive at the same premaster secret as the server (shown by a successful exchange of Finished messages) proves it has the private key for the certified public key, so CertificateVerify is unnecessary 💖
3.3. RSA_fixed_ECDH 🍓
this auth mechanism is identical to ECDSA_fixed_ECDH, except that the client's certificate MUST be signed with RSA 🔥
note that ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH all need the client's cert signed with one particular signature scheme. this spec does NOT put restrictions on the signature schemes used anywhere else in the certificate chain 🧐 (again, those restrictions would often be useful, and CAs are expected to factor that in when they sign stuff, but they're not strictly required in general. even if a server can't fully validate a chain, it might still validate the clients certificate by relying on a trust anchor that shows up as one of the intermediate certs in the chain 🫶)
4. TLS Extensions for ECC 🧚
two new TLS extensions are defined in this spec: (i) the Supported Elliptic Curves Extension, and (ii) the Supported Point Formats Extension ✨ they let you negotiate which specific curves and point formats get used (like compressed vs. uncompressed, respectively) during a handshake that's starting a new session 🎀 these 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 [4], and the message details are in Section 5 📨 the client lists the curves it supports and the point formats it can parse by including the right extensions in its ClientHello message 🦋 the server does the same for point formats it can parse, using an extension in its ServerHello message 💜
a TLS client that proposes ECC cipher suites in its ClientHello message SHOULD include these extensions 🙏 servers that implement ECC cipher suites MUST support these extensions 💅 and when a client uses them, servers MUST NOT negotiate an ECC cipher suite unless they can complete the handshake while respecting the curves and compression techniques the client picked 🚫 this kills the possibility of an ECC handshake getting aborted later because the client can't deal with the server's EC key 😭 no more surprise breakups 💔
the client MUST NOT include these extensions in the ClientHello message if it doesn't propose any ECC cipher suites 🙅♀️ a client that does propose ECC cipher suites may choose not to include these extensions 🤷♀️ in that case the server is free to pick 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 more detail 🤓
in session resumption, the server simply ignores the Supported Elliptic Curves Extension and the Supported Point Formats Extension in the current ClientHello message 🫠 these extensions only matter during handshakes that negotiate a new session 🌈
5. Data Structures and Computations 🍓
this section specifies the data structures and computations used by the ECC-based key mechanisms from Sections 2, 3, and 4 ✨ the presentation language here is the same one used in TLS [2][3] 💖 since this spec extends TLS, these descriptions should be merged with the ones in the TLS spec and any others that extend TLS 🧩 which means enum types might not list every possible value, and structures with multiple formats picked with a select() clause might not show every possible case 🤓
5.1. Client Hello Extensions 💖
okay so bestie, this section is about two TLS extensions that ride along inside the ClientHello message (see [4] for how extensions work in general 🧚). They're the Supported Elliptic Curves Extension and the Supported Point Formats Extension, and together they're basically the client going "hey, here's everything I can handle, pick something that works for both of us" 🫶
When these extensions are sent:
The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites. 🌸
Meaning of these extensions:
They let a client list the elliptic curves it supports and/or the point formats it can parse. Main character energy, honestly 💅
Structure of these extensions:
The general structure of TLS extensions lives in [4], and this spec adds two brand new types to 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. 🦋
- 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. 🌈
Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello appends these extensions (along with any others), listing 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. 🔥
Actions of the receiver:
A server that gets a ClientHello with one or both of these extensions MUST use the client's listed capabilities to guide its choice of 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 the client supports (cf. Sections 5.3 and 5.4). No cap, the server has to actually be able to pull it off ✨
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. 👑
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 sticking to the listed curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. Depending on what other cipher suites the client proposes and the server supports, this may end in a fatal handshake failure alert because there's no common cipher suite. 💀
5.1.1. Supported Elliptic Curves Extension 🍓
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). ✨
The NamedCurve name space is maintained by IANA. See Section 8 for information on how new value assignments are added. 🌸
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 secp192r1, would include a TLS extension made of these octets. Note that the first two octets indicate the extension type (Supported Elliptic Curves Extension):
00 0A 00 06 00 04 00 13 00 15A client that supports arbitrary explicit characteristic-2 curves (value 0xFF02) would include an extension made of these octets:
00 0A 00 04 00 02 FF 025.1.2. Supported Point Formats Extension 🦋
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;Three point formats are in the ECPointFormat definition above. The uncompressed point format is the default in that implementations of this document MUST support it for all of their supported curves. Compressed point formats save 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. 🎀
The ECPointFormat name space is maintained by IANA. See Section 8 for information on how new value assignments are added. 🌈
Items in ec_point_format_list are ordered according to the client's preferences (favorite choice first). ⭐
A client that can parse only the uncompressed point format (value 0) includes an extension made of these octets. Note that the first two octets indicate the extension type (Supported Point Formats Extension):
00 0B 00 02 01 00A client that, for prime fields, prefers the compressed format (ansiX962_compressed_prime, value 1) over the uncompressed format (value 0), but for characteristic-2 fields prefers the uncompressed format (value 0) over the compressed format (ansiX962_compressed_char2, value 2), may signal these preferences with an extension made of these octets:
00 0B 00 04 03 01 00 025.2. Server Hello Extension 🧚
This section specifies one TLS extension that can be included with the ServerHello message (see [4]), the Supported Point Formats Extension. 🫶
When this extension is sent:
The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello containing the Supported Point Formats Extension, when negotiating an ECC cipher suite. 🌸
Meaning of this extension:
This extension lets a server list the point formats it can parse. This is for the curve that will show up in its ServerKeyExchange message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key exchange algorithm, or for the curve used in the server's public key that will show up in its Certificate message when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm. 💅
Structure of this extension:
The server's Supported Point Formats Extension has the same structure as the client's (see Section 5.1.2). Items in elliptic_curve_list here are ordered according to the server's preference (favorite choice first). The server may include items that weren't in the client's list. For example, the server may prefer to receive points in compressed format even when a client can't parse that format, because the same client might still be able to output points in compressed format. 🦋
Actions of the sender:
A server that selects an ECC cipher suite in response to a ClientHello including a Supported Point Formats Extension appends this extension (along with others) to its ServerHello, listing 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. 🔥
Actions of the receiver:
A client that receives a ServerHello 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, that's equivalent to an extension allowing only the uncompressed point format. 🌈
5.3. Server Certificate 🎀
When this message is sent:
This message goes out in all the non-anonymous ECC-based key exchange algorithms 💖
Meaning of this message:
This is how the server authentically hands the client its static public key 🔐 Here's the server certificate type for each key exchange algorithm. Heads up: ECC public keys MUST be encoded in certificates the way Section 5.9 describes 🧚
NOTE: The server's Certificate message can carry a whole chain of certificates. The restrictions in Table 3 only apply to the server's certificate, the first one in the chain.
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
ECDH_ECDSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with ECDSA.
ECDHE_ECDSA Certificate MUST contain an
ECDSA-capable public key. It
MUST be signed with ECDSA.
ECDH_RSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with RSA.
ECDHE_RSA Certificate MUST contain an
RSA public key authorized for
use in digital signatures. It
MUST be signed with RSA.
Table 3: Server Certificate TypesStructure of this message:
It's identical to the TLS Certificate format, so no surprises here 🫶
Actions of the sender:
The server builds an appropriate certificate chain and sends it to the client in the Certificate message ✨ If the client used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves. Basically, the public key MUST use a named curve (not the same curve written out as an explicit curve), unless the client has said it supports explicit curves of the right type 🌸 If the client used a Supported Point Formats Extension, both the server's public key point and (for an explicit curve) the curve's base point MUST respect the client's choice of point formats. And a server that can't meet these requirements MUST NOT choose an ECC cipher suite in its ServerHello message 💀
Actions of the receiver:
The client validates the certificate chain, pulls out the server's public key, and checks that the key type fits the negotiated key exchange algorithm 🕵️♀️ A possible reason for a fatal handshake failure is that the client's elliptic curve and point format abilities got exceeded (see Section 5.1) 😭
5.4. Server Key Exchange 🔑
When this message is sent:
This one gets sent when using the ECDHE_ECDSA, ECDHE_RSA, and ECDH_anon key exchange algorithms 💜
Meaning of this message:
The server uses this to convey its ephemeral ECDH public key, along with the matching elliptic curve domain parameters, to the client ✨
Structure of this message:
enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), reserved(248..255) } ECCurveType;explicit_prime: the elliptic curve domain parameters are spelled out in full, and the underlying finite field is a prime field 🔢explicit_char2: the elliptic curve domain parameters are spelled out in full, and the underlying finite field is a characteristic-2 field 🧮named_curve: a named curve is used. This option SHOULD be used when applicable 🎯
Values 248 through 255 are reserved for private use 🔒
The ECCurveType name space is maintained by IANA. See Section 8 for how new value assignments get added 📋
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
} ECCurve;a,b: these set the coefficients of the elliptic curve. Each value is the byte string form of a field element, made with the conversion routine in Section 4.3.3 of ANSI X9.62 [7] 💅
struct {
opaque point <1..2^8-1>;
} ECPoint;point: this is the byte string form of an elliptic curve point, made with the conversion routine in Section 4.3.6 of ANSI X9.62 [7]. The byte string can be uncompressed or compressed, and it MUST conform to what the client asked for through a Supported Point Formats Extension, if that extension was used 🫧
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;ec_basis_trinomial: a characteristic-2 field represented with a trinomial basis 🧵ec_basis_pentanomial: a characteristic-2 field represented with a pentanomial basis 🧵
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;curve_type: says what kind of elliptic curve domain parameters you're getting 🏷️prime_p: the odd prime that defines the field Fp 🌟curve: specifies the coefficients a and b of the elliptic curve E 📈base: specifies the base point G on the elliptic curve 📍order: specifies the order n of the base point 🔢cofactor: specifies the cofactor h = #E(Fq)/n, where #E(Fq) is the number of points on the elliptic curve E over the field Fq (either Fp or F2^m) 🧠m: the degree of the characteristic-2 field F2^m 📐k: the exponent k for the trinomial basis representation x^m + x^k +1 🪄k1,k2,k3: the exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1, where k3 > k2 > k1 🪄namedcurve: specifies a recommended set of elliptic curve domain parameters. Every NamedCurve value that refers to a specific curve is allowed here. Values that signal support for a whole class of explicitly defined curves are NOT allowed here, since they only make sense in the ClientHello extension. That coversarbitrary_explicit_prime_curves(0xFF01)andarbitrary_explicit_char2_curves(0xFF02)🚫
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;curve_params: specifies the elliptic curve domain parameters tied to the ECDH public key 🎀public: the ephemeral ECDH public key 🦋
The ServerKeyExchange message gets extended like this 🌈
enum { ec_diffie_hellman } KeyExchangeAlgorithm;ec_diffie_hellman: means the ServerKeyExchange message carries an ECDH public key 🥰
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;params: specifies the ECDH public key and its associated domain parameters 🧁signed_params: a hash of the params, with the signature that matches that hash applied. The private key that goes with the certified public key in the server's Certificate message is the one used for signing ✍️
enum { ecdsa } SignatureAlgorithm;
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);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 template above for sha_hash may, accordingly, denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature is a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, whose contents are the DER encoding [9] of the following ASN.1 notation [8].
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}Actions of the sender:
The server picks the elliptic curve domain parameters, plus an ephemeral ECDH public key that matches them, using the ECKAS-DH1 scheme from IEEE 1363 [6] 🧠 Then it sends all that to the client in the ServerKeyExchange message using the format above 🚀
Actions of the receiver:
The client verifies the signature (when one is present) and pulls the server's elliptic curve domain parameters and ephemeral ECDH public key out of the ServerKeyExchange message 🔍 A possible reason for a fatal handshake failure is that the client's elliptic curve and point format abilities got exceeded (see Section 5.1) 😭
5.5. Certificate Request 📜
When this message is sent:
This message goes out when the server is requesting client authentication 🙋♀️
Meaning of this message:
The server uses this message to suggest which client authentication methods it'd be happy with 💖
Structure of this message:
The TLS CertificateRequest message gets extended like this:
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 matching client authentication method from Section 3 🎟️
Actions of the sender:
The server decides which client authentication methods it wants to use, then tells the client using the format above 🫶
Actions of the receiver:
The client figures out whether it has a suitable certificate for any of the requested methods, and whether it wants to go ahead with client authentication at all 🧐
5.6. Client Certificate ✨
okay so when does this message even get sent? 🫶 It goes out in response to a CertificateRequest, but only when the client actually has a suitable certificate and has decided to go ahead with client authentication. 💅
Quick side quest: if the server used a Supported Point Formats Extension, a certificate only counts as suitable for ECDSA_sign, RSA_fixed_ECDH, and ECDSA_fixed_ECDH if the public key point in it respects the server's choice of point formats. 🦋 If there's no Supported Point Formats Extension, the point has to be in uncompressed point format for those methods to work. 🌸
Meaning of this message: this is how the client authentically shares its static public key with the server. 🔑 The table below sums up which client certificate types fit the ECC-based client authentication mechanisms from Section 3. ECC public keys have to be encoded in certificates the way Section 5.9 describes. 🎀
NOTE: The client's Certificate message can carry a chain of certificates. ✨ The restrictions in Table 4 only apply to the client's certificate, which is the first one in the chain. 💜
Client
Authentication Method Client Certificate Type
--------------------- -----------------------
ECDSA_sign Certificate MUST contain an
ECDSA-capable public key and
be signed with 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.
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.
Table 4: Client Certificate TypesStructure of this message: it's identical to the TLS client Certificate format. 🧚
Actions of the sender: the client builds an appropriate certificate chain and sends it to the server in the Certificate message. 💖
Actions of the receiver: the TLS server validates the certificate chain, pulls out the client's public key, and checks that the key type fits the client authentication method. 👑
5.7. Client Key Exchange 🦋
when this gets sent: it's sent in all key exchange algorithms. 💅 If client authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is being used, this message is empty. 🙈 Otherwise, it holds the client's ephemeral ECDH public key. ✨
Meaning of the message: it carries ephemeral data for the key exchange that belongs to the client, like its ephemeral ECDH public key. 🌈
Structure of this message: the TLS ClientKeyExchange message gets extended like so. 🎀
enum { implicit, explicit } PublicValueEncoding;implicit, explicit: for ECC cipher suites, this tells you whether the client's ECDH public key is in the client's certificate ("implicit") or is given as an ephemeral ECDH public key in the ClientKeyExchange message ("explicit"). 💜 It's "explicit" in ECC cipher suites, except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism. 🫶
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;ecdh_Yc: this holds the client's ephemeral ECDH public key as a byte string ECPoint.point. It can represent an elliptic curve point in uncompressed or compressed format. 🍓 Here's the important bit: the format MUST conform to what the server asked for through a Supported Point Formats Extension if that extension was used, and MUST be uncompressed if that extension was not used. 😭
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;Actions of the sender: the client picks an ephemeral ECDH public key that matches the parameters it got from the server, using the ECKAS-DH1 scheme from IEEE 1363 [6]. 🌸 It passes this info along to the client in the ClientKeyExchange message using the format above. 💅
Actions of the receiver: the server grabs the client's ephemeral ECDH public key from the ClientKeyExchange message and checks that it's on the same elliptic curve as the server's ECDH key. 🔥
5.8. Certificate Verify 💜
when this gets sent: it's sent when the client sends a client certificate with a public key that can do digital signatures, for example when the client is authenticated with the ECDSA_sign mechanism. ✨
Meaning of the message: it holds a signature that proves the client has the private key that goes with the public key in its Certificate message. 🔐
Structure of this message: the TLS CertificateVerify message and the underlying Signature type are defined in [2] and [3], and the latter gets extended here in Section 5.4. 🧚 For the ecdsa case, the signature field in the CertificateVerify message holds an ECDSA signature computed over the handshake messages exchanged so far. It works exactly like CertificateVerify with other signing algorithms in [2] and [3]. 🦋
CertificateVerify.signature.sha_hash
SHA(handshake_messages);ECDSA signatures get computed as described in Section 5.10, and SHA in the template above for sha_hash may stand for a hash algorithm other than SHA-1. 🌈 As per ANSI X9.62, an ECDSA signature is a pair of integers, r and s. 🎀 The digitally-signed element gets encoded as an opaque vector <0..2^16-1>, and its contents are the DER encoding [9] of the following ASN.1 notation [8]. 💖
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 that goes with its certified public key to compute the signature, which gets conveyed in the format defined above. 👑
Actions of the receiver: the server pulls the client's signature out of the CertificateVerify message and verifies it using the public key it got in the client's Certificate message. ✨
5.9. Elliptic Curve Certificates 🌸
X.509 certificates that contain ECC public keys or are 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]. 💅
5.10. ECDH, ECDSA, and RSA Computations 🔥
All ECDH calculations are done according to [6] using the ECKAS-DH1 scheme with the identity map as the key derivation function (KDF). 🧚 That includes parameter and key generation as well as the shared secret calculation. ✨ The result is that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point, represented as an octet string. 🦋 That octet string (Z in IEEE 1363 terminology), as output by FE2OSP (the Field Element to Octet String Conversion Primitive), has a constant length for any given field. So leading zeros in it MUST NOT be truncated. 😭
(Okay, technicality alert 🤓: this use of the identity KDF is kind of a technicality. The full picture is that ECDH is used with a non-trivial KDF, because TLS doesn't directly use the premaster secret for anything except computing the master secret. As of TLS 1.0 [2] and 1.1 [3], that means the MD5- and SHA-1-based TLS PRF acts as a KDF. It's conceivable that future TLS versions, or new TLS extensions introduced later, might change this computation. 🌈)
All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. 💜 Data to be signed or verified gets hashed, and the result goes straight through the ECDSA algorithm with no extra 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, like one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public key explicitly requires use of another hash function. 🫶 (The mechanism for specifying the required hash function hasn't been standardized yet, but this provision anticipates that standardization and means this document won't need an update in response. 🙌 Future PKIX RFCs might choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)
All RSA signatures must be generated and verified according to PKCS#1 [12] block type 1. 🔐
6. Cipher Suites ✨
okay so this is the cipher suite menu 💅 the table below defines the new ECC cipher suites that use the key exchange algorithms from Section 2 🎀
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_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_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 suitesThe key exchange method, cipher, and hash algorithm for each of these suites are easy to figure out just by reading the name 🧚 Ciphers (other than AES ciphers) and hash algorithms are defined in [2] and [3]. AES ciphers are defined in [19].
Now the important bit 👑 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_SHATLS_ECDH_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
7. Security Considerations 🔐
okay the security part is literally the most important thing 😭 security issues are discussed all throughout this memo, so keep your eyes open 👀
For TLS handshakes that use ECC cipher suites, the security considerations in appendices D.2 and D.3 of [2] and [3] apply accordingly. Don't skip them 💀
More ECC-specific security discussions live in [6] and [7]. One big issue that implementers and users must consider is how to pick the elliptic curve. Guidance on choosing a good curve size is in Table 1 ✨
Beyond curve size, the main thing is the curve's structure 🦋 As a general rule, it's more conservative to use curves with as little algebraic structure as possible. So random curves are more conservative than special curves like Koblitz curves, and curves over F_p with p random are more conservative than curves over F_p with p of a special form. Curves over F_p with p random might also be considered more conservative than curves over F_2^m, since there's no choice between multiple fields of similar size for characteristic 2 🌸
Ngl, algebraic structure can also make things more efficient, so implementers and users may need to balance being conservative against needing speed. Concrete attacks are known against only a very small number of special classes of curves, like supersingular curves, and those classes are excluded from the ECC standards this document references [6], [7] 🙈
Another issue is the risk of catastrophic failure when a single elliptic curve is used everywhere. If an attack hits that one curve, it could compromise a huge number of keys 😱 This concern may need to be balanced against the efficiency and interoperability gains that come with widely-used curves. You can find lots more on curve choice in [5], [6], [7], and [11] 📚
Implementers and users must also think about whether they need forward secrecy. Forward secrecy means session keys are not compromised if the static, certified keys belonging to the server and client get compromised. The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms give forward secrecy protection if the server's key is compromised, while ECDH_ECDSA and ECDH_RSA do not. Similarly, if the client has a static, certified key, ECDSA_sign client authentication gives forward secrecy protection if the client's key is compromised, while ECDSA_fixed_ECDH and RSA_fixed_ECDH do not.
So, to get complete forward secrecy protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, with ECDSA_sign used for client authentication if necessary. Same energy as always: the security benefits of forward secrecy may need to be balanced against the better efficiency of the other options 💖
8. IANA Considerations 📋
This document describes three new name spaces for use with the TLS protocol:
NamedCurve(Section 5.1)ECPointFormat(Section 5.1)ECCurveType(Section 5.4)
For each name space, this document defines the initial value assignments. It also reserves a range of 256 values for NamedCurve, or eight values for ECPointFormat and ECCurveType, for Private Use. Any additional assignments need IETF Consensus action [16] 🫶
9. Acknowledgements 🌈
The authors wanted to give a huge thank you to Bill Anderson and Tim Dierks 💜
10. References 🧾
10.1. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 📌
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://www.secg.org/>.
[6] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[7] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998.
[8] International Telecommunication Union, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation 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.
[10] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[11] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[12] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", PKCS 1, November 1993.
[13] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 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.
[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.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
10.2. Informative References
[17] Harper, G., Menezes, A., and S. Vanstone, "Public-Key Cryptosystems with Very Small Key Lengths", Advances in Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
[18] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptology 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.
Appendix A. Equivalent Curves (Informative) 🔍
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 table below, multiple names in one row are aliases for the same curve, so one curve can show up under several names 🎀
------------------------------------------
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 NISTAuthors' Addresses 💌
Simon Blake-Wilson
SafeNet Technologies BV
Amstelveenseweg 88-90
1075 XJ, Amsterdam
NL
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
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
Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com
Chris Hawk
Corriente Networks LLC
1563 Solano Ave., #484
Berkeley, CA 94707
US
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
Phone: +49 234 32 26795
EMail: bodo@openssl.orgFull Copyright Statement 💖
Okay so, bestie, the legal stuff is here 📜 Copyright (C) The Internet Society (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. 💅
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. 😭 Ngl, it's a lot of caps, but the gist is: everything comes "as is", and nobody is promising it's perfect. 🫶
Intellectual Property 🦋
So the IETF is not taking a side on whether any Intellectual Property Rights or other rights might apply to the technology described here, or whether anyone can get a license to use it. 🙈 They also haven't gone out and checked for any of these rights themselves. Want the procedures for rights in RFC documents? Check out BCP 78 and BCP 79. 📚
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances of licenses that might be made available. You can also get the result of trying to get a general license or permission for implementers or users of this spec from the IETF online IPR repository at http://www.ietf.org/ipr. 🌐
And if you spot any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, the IETF wants to hear about it! 📣 Send the info to ietf-ipr@ietf.org. 💜
Acknowledgement 🌸
Huge thanks to the people keeping the lights on: funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 🧚✨
That's the end of the document, bestie. We made it! 🌈👑
📦 where this page comes from
- ietf: rfc4492 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms