diff options
author | Simon Josefsson <simon@josefsson.org> | 2004-12-07 22:28:10 +0000 |
---|---|---|
committer | Simon Josefsson <simon@josefsson.org> | 2004-12-07 22:28:10 +0000 |
commit | 3b9e5be62a21047c8922aa8e5bcb0df6953a1f56 (patch) | |
tree | 5a564cdc1888ad051014151dea50eee10313b4ea /doc/protocol/draft-ietf-tls-ecc-07.txt | |
parent | 5346c0fa4b512224447956d759fe143cc72ffccd (diff) | |
download | gnutls-3b9e5be62a21047c8922aa8e5bcb0df6953a1f56.tar.gz |
Add.
Diffstat (limited to 'doc/protocol/draft-ietf-tls-ecc-07.txt')
-rw-r--r-- | doc/protocol/draft-ietf-tls-ecc-07.txt | 1849 |
1 files changed, 1849 insertions, 0 deletions
diff --git a/doc/protocol/draft-ietf-tls-ecc-07.txt b/doc/protocol/draft-ietf-tls-ecc-07.txt new file mode 100644 index 0000000000..48c31d341e --- /dev/null +++ b/doc/protocol/draft-ietf-tls-ecc-07.txt @@ -0,0 +1,1849 @@ + + +TLS Working Group V. Gupta +Internet-Draft Sun Labs +Expires: June 1, 2005 S. Blake-Wilson + BCI + B. Moeller + University of California, Berkeley + C. Hawk + Corriente Networks + N. Bolyard + Dec. 2004 + + + ECC Cipher Suites for TLS + <draft-ietf-tls-ecc-07.txt> + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 1, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes new key exchange algorithms based on Elliptic + + + +Gupta, et al. Expires June 1, 2005 [Page 1] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + Curve Cryptography (ECC) for the TLS (Transport Layer Security) + protocol. In particular, it specifies the use of Elliptic Curve + Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of + Elliptic Curve Digital Signature Algorithm (ECDSA) as a new + authentication mechanism. + + 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]. + + Please send comments on this document to the TLS mailing list. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 + 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 + 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 + 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 + 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 + 5. Data Structures and Computations . . . . . . . . . . . . . . 12 + 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 + 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . 15 + 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 + 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17 + 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 . . . . . . . . . . . . . . . 25 + 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25 + 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 + Intellectual Property and Copyright Statements . . . . . . . 33 + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 2] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +1. Introduction + + Elliptic Curve Cryptography (ECC) is emerging as an attractive + public-key cryptosystem for mobile/wireless environments. Compared + to currently prevalent cryptosystems such as RSA, ECC offers + equivalent security with smaller key sizes. This is illustrated in + the following table, based on [12], which 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) + + + Figure 1 + + Smaller key sizes result in power, bandwidth and computational + savings that make ECC especially attractive for constrained + environments. + + This document describes additions to TLS to support ECC. In + particular, it defines + o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement + scheme with long-term or ephemeral keys to establish the TLS + premaster secret, and + o the use of fixed-ECDH certificates and ECDSA for authentication of + TLS peers. + + The remainder of this document is organized as follows. Section 2 + provides an overview of ECC-based key exchange algorithms for TLS. + Section 3 describes the use of ECC certificates for client + authentication. TLS extensions that allow a client to negotiate the + use of specific curves and point formats are presented in Section 4. + Section 5 specifies various data structures needed for an ECC-based + handshake, their encoding in TLS messages and the processing of those + messages. Section 6 defines new ECC-based cipher suites and + identifies a small subset of these as recommended for all + implementations of this specification. Section 7 and Section 8 + mention security considerations and acknowledgments, respectively. + This is followed by a list of references cited in this document, the + authors' contact information, and statements on intellectual property + + + +Gupta, et al. Expires June 1, 2005 [Page 3] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + rights and copyrights. + + Implementation of this specification requires familiarity with TLS + [2], TLS extensions [3] and ECC [4][5][6][8] . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 4] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +2. Key Exchange Algorithms + + This document introduces five new ECC-based key exchange algorithms + for TLS. All of them use ECDH to compute the TLS premaster secret + and differ only in the lifetime of ECDH keys (long-term or ephemeral) + and the mechanism (if any) used to authenticate them. The derivation + of the TLS master secret from the premaster secret and the subsequent + generation of bulk encryption/MAC keys and initialization vectors is + independent of the key exchange algorithm and not impacted by the + introduction of ECC. + + The table below summarizes the new key exchange algorithms which + mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]), + 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 algorithms + + + Figure 2 + + The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward + secrecy. With ECDHE_RSA, a server can reuse its existing RSA + certificate and easily comply with a constrained client's elliptic + curve preferences (see Section 4). However, the computational cost + incurred by a server is higher for ECDHE_RSA than for the traditional + RSA key exchange which does not provide forward secrecy. + + The ECDH_RSA mechanism requires a server to acquire an ECC + certificate but the certificate issuer can still use an existing RSA + key for signing. This eliminates the need to update the trusted key + store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for + the server as well as the certification authority and is best suited + + + +Gupta, et al. Expires June 1, 2005 [Page 5] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + for constrained devices unable to support RSA. + + The anonymous key exchange algorithm does not provide authentication + of the server or the client. Like other anonymous TLS key exchanges, + it is subject to man-in-the-middle attacks. Implementations of this + algorithm SHOULD provide authentication by other means. + + Note that there is no structural difference between ECDH and ECDSA + keys. A certificate issuer may use X509.v3 keyUsage and + extendedKeyUsage extensions to restrict the use of an ECC public key + to certain computations. This document refers to an ECC key as + ECDH-capable if its use in ECDH is permitted. ECDSA-capable is + defined similarly. + + + Client Server + ------ ------ + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest*+ + <-------- ServerHelloDone + Certificate*+ + ClientKeyExchange + CertificateVerify*+ + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + + Application Data <-------> Application Data + + Figure 1: Message flow in a full TLS handshake + * message is not sent under some conditions + + message is not sent unless the client is + authenticated + + + Figure 3 + + Figure 1 shows all messages involved in the TLS key establishment + protocol (aka full handshake). The addition of ECC has direct impact + only on the ClientHello, the ServerHello, the server's Certificate + message, the ServerKeyExchange, the ClientKeyExchange, the + CertificateRequest, the client's Certificate message, and the + CertificateVerify. Next, we describe each ECC key exchange algorithm + + + +Gupta, et al. Expires June 1, 2005 [Page 6] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + 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. + +2.1 ECDH_ECDSA + + In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable + public key and be signed with ECDSA. + + A ServerKeyExchange MUST NOT be sent (the server's certificate + contains all the necessary keying information required by the client + to arrive at the premaster secret). + + The client MUST generate an ECDH key pair on the same curve as the + server's long-term public key and send its public key in the + ClientKeyExchange message (except when using client authentication + algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the + modifications from section Section 3.2 or Section 3.3 apply). + + Both client and server MUST 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 + +2.2 ECDHE_ECDSA + + In ECDHE_ECDSA, the server's certificate MUST contain an + ECDSA-capable public key and be signed with ECDSA. + + The server MUST send its ephemeral ECDH public key and a + specification of the corresponding curve in the ServerKeyExchange + message. These parameters MUST be signed with ECDSA using the + private key corresponding to the public key in the server's + Certificate. + + The client MUST generate an ECDH key pair on the same curve as the + server's ephemeral ECDH key and send its public key in the + ClientKeyExchange message. + + Both client and server MUST perform an ECDH operation (Section 5.10) + and use the resultant shared secret as the premaster secret. + +2.3 ECDH_RSA + + This key exchange algorithm is the same as ECDH_ECDSA except the + server's certificate MUST be signed with RSA rather than ECDSA. + + + + +Gupta, et al. Expires June 1, 2005 [Page 7] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +2.4 ECDHE_RSA + + This key exchange algorithm is the same as ECDHE_ECDSA except 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. The server + certificate MUST be signed with RSA. + +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. + + 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. + + The client MUST generate an ECDH key pair on the same curve as the + server's ephemeral ECDH key and send its public key in the + ClientKeyExchange message. + + Both client and server MUST 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 + + + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 8] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +3. Client Authentication + + This document defines three new client authentication mechanisms + named after the type of client certificate involved: ECDSA_sign, + ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is + usable with any of the non-anonymous ECC key exchange algorithms + described in Section 2 as well as other non-anonymous (non-ECC) key + exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and + RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. + Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the + use of a long-term ECDH client key would jeopardize the forward + secrecy property of these algorithms. + + The server can request ECC-based client authentication by including + one or more of these certificate types in its CertificateRequest + message. The server MUST NOT include any certificate types that are + prohibited for the negotiated key exchange algorithm. The client + must check if it possesses a certificate appropriate for any of the + methods suggested by the server and is willing to use it for + authentication. + + If these conditions are not met, the client should send a client + Certificate message containing no certificates. In this case, the + ClientKeyExchange should be sent as described in Section 2 and the + CertificateVerify should not be sent. If the server requires client + authentication, it may respond with a fatal handshake failure alert. + + If the client has an appropriate certificate and is willing to use it + for authentication, it MUST send that certificate in the client's + Certificate message (as per Section 5.6) and prove possession of the + private key corresponding to the certified key. The process of + determining an appropriate certificate and proving possession is + different for each authentication mechanism and described below. + + 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 authentication mechanism, the client MUST possess a + certificate containing an ECDSA-capable public key and signed with + ECDSA. + + The client MUST prove possession of the private key corresponding to + the certified key by including a signature in the CertificateVerify + message as described in Section 5.8. + + + + +Gupta, et al. Expires June 1, 2005 [Page 9] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +3.2 ECDSA_fixed_ECDH + + To use this authentication mechanism, the client MUST possess a + certificate containing an ECDH-capable public key and that + certificate MUST be signed with ECDSA. Furthermore, the client's + ECDH key MUST be on the same elliptic curve as the server's long-term + (certified) ECDH key. This might limit use of this mechanism to + closed environments. In situations where the client has an ECC key + on a different curve, it would have to authenticate either using + ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for + both servers and clients is computationally more efficient than + mechanisms providing forward secrecy. + + When using this authentication mechanism, the client MUST send an + empty ClientKeyExchange as described in Section 5.7 and MUST NOT send + the CertificateVerify message. The ClientKeyExchange is empty since + the client's ECDH public key required by the server to compute the + premaster secret is available inside the client's certificate. The + client's ability to arrive at the same premaster secret as the server + (demonstrated by a successful exchange of Finished messages) proves + possession of the private key corresponding to the certified public + key and the CertificateVerify message is unnecessary. + +3.3 RSA_fixed_ECDH + + This authentication mechanism is identical to ECDSA_fixed_ECDH except + the client's certificate MUST be signed with RSA. + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 10] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +4. TLS Extensions for ECC + + Two new TLS extensions --- (i) the Supported Elliptic Curves + Extension, and (ii) the Supported Point Formats Extension --- allow a + client to negotiate the use of specific curves and point formats + (e.g. compressed v/s uncompressed), respectively. 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 [3]. The client enumerates the curves and point + formats it supports by including the appropriate extensions in its + ClientHello message. By echoing that extension in its ServerHello, + the server agrees to restrict its key selection or encoding to the + choices specified by the client. + + 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 negotiate the use of + an ECC cipher suite only if they can complete the handshake while + limiting themselves to the curves and compression techniques + enumerated 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. + + These extensions MUST NOT be included if the client does not propose + any ECC cipher suites. A client that proposes ECC cipher suites may + choose not to include these extension. 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. + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 11] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +5. Data Structures and Computations + + This section specifies the data structures and computations used by + ECC-based key mechanisms specified in Section 2, Section 3 and + Section 4. The presentation language used here is the same as that + used in TLS [2]. 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. + +5.1 Client Hello Extensions + + When this message is sent: + + The ECC extensions SHOULD be sent along with any ClientHello message + that proposes ECC cipher suites. + + Meaning of this message: + + These extensions allow a constrained client to enumerate the elliptic + curves and/or point formats it supports. + + Structure of this message: + + The general structure of TLS extensions is described in [3] and this + specification adds two new types to ExtensionType. + + + enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; + + elliptic_curves: Indicates the set of elliptic curves supported by + the client. For this extension, the opaque extension_data field + contains EllipticCurveList. + ec_point_formats: Indicates the set of point formats supported by + the client. For this extension, the opaque extension_data field + contains ECPointFormatList. + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 12] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + 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 (240..247), + arbitrary_explicit_prime_curves(253), + arbitrary_explicit_char2_curves(254), + (255) + } NamedCurve; + + sect163k1, etc: Indicates support of the corresponding named curve + specified in SEC 2 [10]. Note that many of these curves are also + recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 + through 247 are reserved for private use. Values 253 and 254 + indicate that the client supports arbitrary prime and + characteristic-2 curves, respectively (the curve parameters must + be encoded explicitly in ECParameters). + + + struct { + NamedCurve elliptic_curve_list<1..2^8-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) + and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would + include an elliptic_curves extension with the following octets: + + 00 ?? 02 13 15 + + A client that supports arbitrary explicit binary polynomial curves + would include an extension with the following octets: + + 00 ?? 01 fe + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 13] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + enum { uncompressed (0), ansiX963_compressed (1), + ansiX963_hybrid (2), (255) + } ECPointFormat; + + struct { + ECPointFormat ec_point_format_list<1..2^8-1> + } ECPointFormatList; + + Three point formats are included in the defintion of ECPointFormat + above. The uncompressed point format is the default format that + implementations of this document MUST support. The + ansix963_compressed format reduces bandwidth by including only the + x-coordinate and a single bit of the y-coordinate of the point. The + ansix963_hybrid format includes both the full y-coordinate and the + compressed y-coordinate to allow flexibility and improve efficiency + in some cases. Implementations of this document MAY support the + ansix963_compressed and ansix963_hybrid point formats. + + Items in ec_point_format_list are ordered according to the client's + preferences (favorite choice first). + + A client that only supports the uncompressed point format includes an + extension with the following octets: + + 00 ?? 01 00 + + A client that prefers the use of the ansiX963_compressed format over + uncompressed may indicate that preference by including an extension + with the following octets: + + 00 ?? 02 01 00 + + Actions of the sender: + + A client that proposes ECC cipher suites in its ClientHello appends + these extensions (along with any others) enumerating the curves and + point formats it supports. + + 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. + + NOTE: A server participating in an ECDHE-ECDSA key exchange may use + + + +Gupta, et al. Expires June 1, 2005 [Page 14] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + 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 "elliptic_curves" extension in selecting both of + these curves. + + If a server does not understand the "elliptic_curves" extension or is + unable to complete the ECC handshake while restricting itself to the + enumerated curves, 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. + +5.2 Server Hello Extensions + + When this message is sent: + + The ServerHello ECC extensions are sent in response to a Client Hello + message containing ECC extensions when negotiating an ECC cipher + suite. + + Meaning of this message: + + These extensions indicate the server's agreement to use only the + elliptic curves and point formats supported by the client during the + ECC-based key exchange. + + Structure of this message: + + The ECC extensions echoed by the server are the same as those in the + ClientHello except the "extension_data" field is empty. + + For example, a server indicates its acceptance of the client's + elliptic_curves extension by sending an extension with the following + octets: + + 00 ?? 00 00 + + Actions of the sender: + + A server makes sure that it can complete a proposed ECC key exchange + mechanism by restricting itself to the curves/point formats supported + by the client before sending these extensions. + + Actions of the receiver: + + A client that receives a ServerHello with ECC extensions proceeds + with an ECC key exchange assured that it will be able to handle the + server's EC key(s). + + + +Gupta, et al. Expires June 1, 2005 [Page 15] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +5.3 Server Certificate + + When this message is sent: + + This message is sent in all non-anonymous ECC-based key exchange + algorithms. + + 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. + + NOTE: The server's Certificate message is capable of carrying a chain + of certificates. The restrictions mentioned in Table 3 apply only to + the server's certificate (first in the chain). + + + 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 types + + + Structure of this message: + + Identical to the TLS Certificate format. + + Actions of the sender: + + + +Gupta, et al. Expires June 1, 2005 [Page 16] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + The server constructs an appropriate certificate chain and conveys it + to the client in the Certificate message. + + 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. + +5.4 Server Key Exchange + + When this message is sent: + + This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and + ECDH_anon key exchange algorithms. + + 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. + + Structure of this message: + + enum { explicit_prime (1), explicit_char2 (2), + named_curve (3), (255) } ECCurveType; + + explicit_prime: Indicates the elliptic curve domain parameters are + conveyed verbosely, and the underlying finite field is a prime + field. + explicit_char2: Indicates the elliptic curve domain parameters are + conveyed verbosely, and the underlying finite field is a + characteristic-2 field. + named_curve: Indicates that a named curve is used. This option + SHOULD be used when applicable. + + struct { + opaque a <1..2^8-1>; + opaque b <1..2^8-1>; + } ECCurve; + + a, b: These parameters specify the coefficients of the elliptic + curve. Each value contains the byte string representation of a + field element following the conversion routine in Section 4.3.3 of + ANSI X9.62 [6]. + + struct { + opaque point <1..2^8-1>; + + + +Gupta, et al. Expires June 1, 2005 [Page 17] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + } 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 [6]. Note that this byte string may represent an elliptic + curve point in compressed or uncompressed form. + + enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; + + ec_basis_trinomial: Indicates representation of a characteristic-2 + field using a trinomial basis. + ec_basis_pentanomial: Indicates representation of a characteristic-2 + field using 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: This identifies the type of the elliptic curve domain + parameters. + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 18] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + prime_p: This is the odd prime defining 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) + represents the number of points on the elliptic curve E defined + over the field Fq. + m: This is 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 (such that k3 > k2 > k1). + namedcurve: Specifies a recommended set of elliptic curve domain + parameters. All enum values of NamedCurve are allowed except for + arbitrary_explicit_prime_curves(253) and + arbitrary_explicit_char2_curves(254). These two values are only + allowed in the ClientHello extension. + + struct { + ECParameters curve_params; + ECPoint public; + } ServerECDHParams; + + curve_params: Specifies the elliptic curve domain parameters + associated with the ECDH public key. + public: The ephemeral ECDH public key. + + The ServerKeyExchange message is extended as follows. + + enum { ec_diffie_hellman } KeyExchangeAlgorithm; + + ec_diffie_hellman: Indicates the ServerKeyExchange message contains + an ECDH public key. + + select (KeyExchangeAlgorithm) { + case ec_diffie_hellman: + ServerECDHParams params; + Signature signed_params; + } ServerKeyExchange; + + params: Specifies the ECDH public key and associated domain + parameters. + 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. + + enum { ecdsa } SignatureAlgorithm; + + + +Gupta, et al. Expires June 1, 2005 [Page 19] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + select (SignatureAlgorithm) { + case ecdsa: + digitally-signed struct { + opaque sha_hash[sha_size]; + }; + } Signature; + + NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange + algorithm and 'anonymous' for ECDH_anon. These cases are defined in + TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA + signatures are generated and verified as described in Section 5.10. + As per ANSI X9.62, an ECDSA signature consists of a pair of integers + r and s. These integers are both converted into byte strings of the + same length as the curve order n using the conversion routine + specified in Section 4.3.1 of [6]. The two byte strings are + concatenated, and the result is placed in the signature field. + + 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 [5]. It conveys this information to + the client in the ServerKeyExchange message using the format defined + above. + + Actions of the recipient: + + 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. + +5.5 Certificate Request + + 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. + + enum { + ecdsa_sign(?), rsa_fixed_ecdh(?), + + + +Gupta, et al. Expires June 1, 2005 [Page 20] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + ecdsa_fixed_ecdh(?), (255) + } ClientCertificateType; + + ecdsa_sign, etc Indicates that the server would like to use the + corresponding client authentication method specified in Section 3. + EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and + ecdsa_fixed_ecdh have been left as ?. These values will be + assigned when this draft progresses to RFC. Earlier versions of + this draft used the values 5, 6, and 7 - however these values have + been removed since they are used differently by SSL 3.0 [13] and + their use by TLS is being deprecated. + + 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 an appropriate certificate for + use with any of the requested methods, and decides whether or not to + proceed with client authentication. + +5.6 Client Certificate + + When this message is sent: + + This message is sent in response to a CertificateRequest when a + client has a suitable certificate. + + Meaning of this message: + + This message is used to authentically convey the client's static + public key to the server. The following table summarizes what client + certificate types are appropriate for the ECC-based client + authentication mechanisms described in Section 3. ECC public keys + must be encoded in certificates as described in Section 5.9. + + NOTE: The client's Certificate message is capable of carrying a chain + of certificates. The restrictions mentioned in Table 4 apply only to + the client's certificate (first in the chain). + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 21] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + 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 types + + + Structure of this message: + + Identical to the TLS client Certificate format. + + 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. + +5.7 Client Key Exchange + + When this message is sent: + + This message is sent in all key exchange algorithms. If client + authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this + message is empty. Otherwise, it contains the client's ephemeral ECDH + public key. + + Meaning of the message: + + + +Gupta, et al. Expires June 1, 2005 [Page 22] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + This message is used to convey ephemeral data relating to the key + exchange belonging to the client (such as its ephemeral ECDH public + key). + + Structure of this message: + + The TLS ClientKeyExchange message is extended as follows. + + enum { yes, no } EphemeralPublicKey; + + yes, no: Indicates whether or not the client is providing an + ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" + except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH + client authentication mechanism.) + + struct { + select (EphemeralPublicKey) { + case yes: ECPoint ecdh_Yc; + case no: struct { }; + } ecdh_public; + } ClientECDiffieHellmanPublic; + + ecdh_Yc: Contains the client's ephemeral ECDH public key. + + struct { + select (KeyExchangeAlgorithm) { + case ec_diffie_hellman: ClientECDiffieHellmanPublic; + } exchange_keys; + } ClientKeyExchange; + + Actions of the sender: + + The client selects an ephemeral ECDH public key corresponding to the + parameters it received from the server according to the ECKAS-DH1 + scheme from IEEE 1363 [5]. It conveys this information to the client + in the ClientKeyExchange message using the format defined above. + + Actions of the recipient: + + 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. + +5.8 Certificate Verify + + When this message is sent: + + This message is sent when the client sends a client certificate + + + +Gupta, et al. Expires June 1, 2005 [Page 23] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + containing a public key usable for digital signatures, e.g. when the + client is authenticated using the ECDSA_sign mechanism. + + 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 is extended as follows. + + enum { ecdsa } SignatureAlgorithm; + + select (SignatureAlgorithm) { + case ecdsa: + digitally-signed struct { + opaque sha_hash[sha_size]; + }; + } Signature; + + For the ecdsa case, the signature field in the CertificateVerify + message contains an ECDSA signature computed over handshake messages + exchanged so far. ECDSA signatures are computed as described in + Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a + pair of integers r and s. These integers are both converted into + byte strings of the same length as the curve order n using the + conversion routine specified in Section 4.3.1 of [6]. The two byte + strings are concatenated, and the result is placed in the signature + field. + + Actions of the sender: + + The client computes its signature over all handshake messages sent or + received starting at client hello 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. + + 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. + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 24] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +5.9 Elliptic Curve Certificates + + X509 certificates containing ECC public keys or signed using ECDSA + MUST comply with [11] or another RFC that replaces or extends it. + Clients SHOULD use the elliptic curve domain parameters recommended + in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. + +5.10 ECDH, ECDSA and RSA Computations + + All ECDH calculations (including parameter and key generation as well + as the shared secret calculation) MUST be performed according to [5] + using the ECKAS-DH1 scheme with the identity map as key derivation + function, so that the premaster secret is the x-coordinate of the + ECDH shared secret elliptic curve point, i.e. the octet string Z in + IEEE 1363 terminology. + + Note that a new extension may be introduced in the future to allow + the use of a different KDF during computation of the premaster + secret. In this event, the new KDF would be used in place of the + process detailed above. This may be desirable, for example, to + support compatibility with the planned NIST key agreement standard. + + All ECDSA computations MUST be performed according to ANSI X9.62 [6] + or its successors. Data to be signed/verified is hashed and the + result run directly through the ECDSA algorithm with no additional + hashing. The default hash function is SHA-1 [7] and sha_size (see + Section 5.4 and Section 5.8) is 20. However, an alternative hash + function, such as one of the new SHA hash functions specified in FIPS + 180-2 [7], 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 has not been + standardized but this provision anticipates such standardization and + obviates the need to update this document in response. Future PKIX + RFCs may choose, for example, to specify the hash function to be used + with a public key in the parameters field of subjectPublicKeyInfo.) + + All RSA signatures must be generated and verified according to PKCS#1 + [9]. + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 25] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +6. Cipher Suites + + The table below defines new ECC cipher suites that use the key + exchange algorithms specified in Section 2. + + CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } + + CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } + + CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } + + CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } + + CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } + CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } + + Table 5: TLS ECC cipher suites + + + Figure 30 + + The key exchange method, cipher, and hash algorithm for each of these + cipher suites are easily determined by examining the name. Ciphers + other than AES ciphers, and hash algorithms are defined in [2]. AES + ciphers are defined in [14]. + + Server implementations SHOULD support all of the following cipher + suites, and client implementations SHOULD support at least one of + + + +Gupta, et al. Expires June 1, 2005 [Page 26] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, + TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, + TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and + TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 27] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +7. Security Considerations + + This document is based on [2], [5], [6] and [14]. The appropriate + security considerations of those documents apply. + + One important issue that implementors and users must consider is + elliptic curve selection. Guidance on selecting an appropriate + elliptic curve size is given in Figure 1. + + Beyond elliptic curve size, the main issue is elliptic curve + structure. As a general principle, it is more conservative to use + elliptic curves with as little algebraic structure as possible - thus + random curves are more conservative than special curves such as + Koblitz curves, and curves over F_p with p random are more + conservative than curves over F_p with p of a special form (and + curves over F_p with p random might be considered more conservative + than curves over F_2^m as there is no choice between multiple fields + of similar size for characteristic 2). Note, however, that algebraic + structure can also lead to implementation efficiencies and + implementors and users may, therefore, need to balance conservatism + against a need for efficiency. Concrete attacks are known against + only very few special classes of curves, such as supersingular + curves, and these classes are excluded from the ECC standards that + this document references [5], [6]. + + 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 [4], [5], [6], [8]. + + Implementors and users must also consider whether they need forward + secrecy. Forward secrecy refers to the property that session keys + are not compromised if the static, certified keys belonging to the + server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key + exchange algorithms provide forward secrecy protection in the event + of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. + Similarly if the client is providing a static, certified key, + ECDSA_sign client authentication provides forward secrecy protection + in the event of client key compromise, while ECDSA_fixed_ECDH and + RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy + protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, + with ECDSA_sign used for client authentication if necessary. Here + again the security benefits of forward secrecy may need to be + balanced against the improved efficiency offered by other options. + + + + +Gupta, et al. Expires June 1, 2005 [Page 28] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +8. Acknowledgments + + The authors wish to thank Bill Anderson and Tim Dierks. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 29] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +9. References + +9.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] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and + T. Wright, "Transport Layer Security (TLS) Extensions", + draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004. + + [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, + <http://www.secg.org/>. + + [5] IEEE, "Standard Specifications for Public Key Cryptography", + IEEE 1363, 2000. + + [6] ANSI, "Public Key Cryptography For The Financial Services + Industry: The Elliptic Curve Digital Signature Algorithm + (ECDSA)", ANSI X9.62, 1998. + + [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. + + [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. + + [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version + 1.5", PKCS 1, November 1993. + + [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, + 2000, <http://www.secg.org/>. + + [11] 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. + +9.2 Informative References + + [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", Journal of Cryptology 14 (2001) 255-293, + <http://www.cryptosavvy.com/>. + + [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol + Version 3.0", November 1996, + <http://wp.netscape.com/eng/ssl3/draft302.txt>. + + + +Gupta, et al. Expires June 1, 2005 [Page 30] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for + Transport Layer Security (TLS)", RFC 3268, June 2002. + + [15] Hovey, R. and S. Bradner, "The Organizations Involved in the + IETF Standards Process", RFC 2028, BCP 11, October 1996. + + +Authors' Addresses + + Vipul Gupta + Sun Microsystems Laboratories + 16 Network Circle + MS UMPK16-160 + Menlo Park, CA 94025 + USA + + Phone: +1 650 786 7551 + EMail: vipul.gupta@sun.com + + + Simon Blake-Wilson + Basic Commerce & Industries, Inc. + 96 Spandia Ave + Unit 606 + Toronto, ON M6G 2T6 + Canada + + Phone: +1 416 214 5961 + EMail: sblakewilson@bcisse.com + + + Bodo Moeller + University of California, Berkeley + EECS -- Computer Science Division + 513 Soda Hall + Berkeley, CA 94720-1776 + USA + + EMail: bodo@openssl.org + + + Chris Hawk + Corriente Networks + + EMail: chris@corriente.net + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 31] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + + Nelson Bolyard + + EMail: nelson@bolyard.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gupta, et al. Expires June 1, 2005 [Page 32] + +Internet-Draft ECC Cipher Suites for TLS Dec. 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). 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. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Gupta, et al. Expires June 1, 2005 [Page 33] + + |