Add.

1 files changed, 1960 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-ecc-09.txt b/doc/protocol/draft-ietf-tls-ecc-09.txt
new file mode 100644
index 0000000000..8efbae5f95
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-ecc-09.txt
@@ -0,0 +1,1960 @@
+
+
+TLS Working Group                                               V. Gupta
+Internet-Draft                                                  Sun Labs
+Expires: October 9, 2005                                 S. Blake-Wilson
+                                                                     BCI
+                                                              B. Moeller
+                                                   University of Calgary
+                                                                 C. Hawk
+                                                      Corriente Networks
+                                                              N. Bolyard
+                                                           April 7, 2005
+
+
+                       ECC Cipher Suites for TLS
+                      <draft-ietf-tls-ecc-09.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 October 9, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+
+
+
+Gupta, et al.            Expires October 9, 2005                [Page 1]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   This document describes new key exchange algorithms based on Elliptic
+   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  . . . . . . . . . . . . . . . . . . . . . . . .   7
+     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 Extension . . . . . . . . . . . . . . . . . .  15
+     5.3  Server Certificate . . . . . . . . . . . . . . . . . . . .  16
+     5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . .  18
+     5.5  Certificate Request  . . . . . . . . . . . . . . . . . . .  22
+     5.6  Client Certificate . . . . . . . . . . . . . . . . . . . .  23
+     5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . .  24
+     5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . .  25
+     5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . .  26
+     5.10   ECDH, ECDSA and RSA Computations . . . . . . . . . . . .  26
+   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  28
+   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  30
+   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  31
+   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  32
+     9.1  Normative References . . . . . . . . . . . . . . . . . . .  32
+     9.2  Informative References . . . . . . . . . . . . . . . . . .  32
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  33
+        Intellectual Property and Copyright Statements . . . . . . .  35
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005                [Page 2]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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 [13], 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)
+
+
+   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 October 9, 2005                [Page 3]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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 October 9, 2005                [Page 4]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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, DHE_DSS, DH_RSA, 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
+
+
+   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
+   for constrained devices unable to support RSA.
+
+   The anonymous key exchange algorithm does not provide authentication
+
+
+
+Gupta, et al.            Expires October 9, 2005                [Page 5]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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
+
+
+                   * message is not sent under some conditions
+                   + message is not sent unless client authentication
+                     is desired
+
+                 Figure 1: Message flow in a full TLS handshake
+
+
+   Figure 1 shows all messages involved in the TLS key establishment
+   protocol (aka full handshake).  The addition of ECC has direct impact
+   only on the ClientHello, the ServerHello, the server's Certificate
+   message, the ServerKeyExchange, the ClientKeyExchange, the
+   CertificateRequest, the client's Certificate message, and the
+   CertificateVerify.  Next, we describe each ECC key exchange algorithm
+   in greater detail in terms of the content and processing of these
+   messages.  For ease of exposition, we defer discussion of client
+   authentication and associated messages (identified with a + in
+
+
+
+Gupta, et al.            Expires October 9, 2005                [Page 6]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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.
+
+2.4  ECDHE_RSA
+
+   This key exchange algorithm is the same as ECDHE_ECDSA except the
+
+
+
+Gupta, et al.            Expires October 9, 2005                [Page 7]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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 October 9, 2005                [Page 8]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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 October 9, 2005                [Page 9]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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 October 9, 2005               [Page 10]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+4.  TLS Extensions for ECC
+
+   Two new TLS extensions are defined in this specification: (i) the
+   Supported Elliptic Curves Extension, and (ii) the Supported Point
+   Formats Extension.  These allow negotiating the use of specific
+   curves and point formats (e.g. compressed vs. uncompressed),
+   respectively, during a handshake starting a new session.  These
+   extensions are especially relevant for constrained clients that may
+   only support a limited number of curves or point formats.  They
+   follow the general approach outlined in [3]; message details are
+   specified in Section 5.  The client enumerates the curves it supports
+   and the point formats it can parse by including the appropriate
+   extensions in its ClientHello message.  The server similarly
+   enumerates the point formats it can parse by including an extension
+   in its ServerHello message.
+
+   A TLS client that proposes ECC cipher suites in its ClientHello
+   message SHOULD include these extensions.  Servers implementing ECC
+   cipher suites MUST support these extensions, and when a client uses
+   these extensions, servers MUST NOT negotiate the use of an ECC cipher
+   suite unless they can complete the handshake while respecting the
+   choice of curves and compression techniques specified by the client.
+   This eliminates the possibility that a negotiated ECC handshake will
+   be subsequently aborted due to a client's inability to deal with the
+   server's EC key.
+
+   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.
+
+   In the case of session resumption, the server simply ignores the
+   Supported Elliptic Curves Extension and the Supported Point Formats
+   Extension as appearing in the current ClientHello message.  These
+   extensions only play a role during handshakes negotiating a new
+   session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 11]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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
+
+   This section specifies two TLS extensions that can be included with
+   the ClientHello message as described in [3], the Supported Elliptic
+   Curves Extension and the Supported Point Formats Extension.
+
+   When these extensions are sent:
+
+   The extensions SHOULD be sent along with any ClientHello message that
+   proposes ECC cipher suites.
+
+   Meaning of these extensions:
+
+   These extensions allow a client to enumerate the elliptic curves it
+   supports and/or the point formats it can parse.
+
+   Structure of these extensions:
+
+   The general structure of TLS extensions is described in [3] and this
+   specification adds two new types to ExtensionType.
+
+
+       enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
+
+   [[ EDITOR: The values used for elliptic_curves and ec_point_formats
+   have been left as ??.  These values will be assigned when this draft
+   progresses to RFC.  (The examples below will have to be changed
+   accordingly.) ]]
+
+   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.
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 12]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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.
+
+
+        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;
+   value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and
+   prefers to use secp192r1 would include a TLS extension consisting of
+   the following octets:
+
+        00 ?? 00 03 02 13 15
+
+   A client that supports arbitrary explicit characteristic-2 curves
+   (value 254 = 0xFE) would include an extension consisting of the
+   following octets:
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 13]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+        00 ?? 00 02 01 FE
+
+
+        enum { uncompressed (0), ansiX962_compressed (1),
+               ansiX962_hybrid (2), reserved (3 .. 255)
+        } ECPointFormat;
+
+        struct {
+            ECPointFormat ec_point_format_list<1..2^8-1>
+        } ECPointFormatList;
+
+   Three point formats are included in the definition of ECPointFormat
+   above.  The uncompressed point format is the default format in that
+   implementations of this document MUST support it.  The
+   ansiX962_compressed format reduces bandwidth by including only the
+   x-coordinate and a single bit of the y-coordinate of the point.  The
+   ansiX962_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
+   ansiX962_compressed and ansiX962_hybrid point formats.  (These three
+   formats are described in [6].)  Values 248 through 255 are reserved
+   for private use.
+
+   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 includes
+   an extension consisting of the following octets:
+
+        00 ?? 00 02 01 00
+
+   A client that prefers the use of the ansiX962_compressed format over
+   uncompressed may indicate that preference by including an extension
+   consisting of the following octets:
+
+        00 ?? 00 03 02 01 00
+
+   Actions of the sender:
+
+   A client that proposes ECC cipher suites in its ClientHello message
+   appends these extensions (along with any others), enumerating the
+   curves it supports and the point formats it can parse.  Clients
+   SHOULD send both the Supported Elliptic Curves Extension and the
+   Supported Point Formats Extension.  If the Supported Point Formats
+   Extension is indeed sent, it MUST contain the value 0 (uncompressed)
+   as one of the items in the list of point formats.
+
+   Actions of the receiver:
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 14]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   A server that receives a ClientHello containing one or both of these
+   extensions MUST use the client's enumerated capabilities to guide its
+   selection of an appropriate cipher suite.  One of the proposed ECC
+   cipher suites must be negotiated only if the server can successfully
+   complete the handshake while using the curves and point formats
+   supported by the client (cf. Section 5.3 and Section 5.4).
+
+   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
+   different curves for (i) the ECDSA key in its certificate, and (ii)
+   the ephemeral ECDH key in the ServerKeyExchange message.  The server
+   must consider the "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 Extension
+
+   This section specifies a TLS extension that can be included with the
+   ServerHello message as described in [3], 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 message containing the Supported
+   Point Formats Extension when negotiating an ECC cipher suite.
+
+   Meaning of this extensions:
+
+   This extension allows a server to enumerate the point formats it can
+   parse (for the curve that will appear in its ServerKeyExchange
+   message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
+   exchange algorithm, or for the curve that is used in the server's
+   public key that will appear in its Certificate message when using the
+   ECDH_ECDSA or ECDH_RSA key exchange algorithm).
+
+   Structure of this extension:
+
+   The server's Supported Point Formats Extension has the same structure
+   as the client's Supported Point Formats Extension.  Items in
+   elliptic_curve_list here are ordered according to the server's
+   preference (favorite choice first).  Note that the server may include
+   items that were not found in the client's list (e.g., the server may
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 15]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   prefer to receive points in compressed format even when a client
+   cannot parse this format: the same client may nevertheless be capable
+   to output points in compressed format).
+
+   Actions of the sender:
+
+   A server that selects an ECC cipher suite in response to a
+   ClientHello message including a Supported Point Formats Extension
+   appends this extension (along with others) to its ServerHello
+   message, enumerating the point formats it can parse.  The Supported
+   Point Formats Extension, when used, MUST contain the value 0
+   (uncompressed) as one of the items in the list of point formats.
+
+   Actions of the receiver:
+
+   A client that receives a ServerHello message containing a Supported
+   Point Formats Extension MUST respect the server's choice of point
+   formats during the handshake (cf. Section 5.6 and Section 5.7).  If
+   no Supported Point Formats Extension is received with the
+   ServerHello, this is equivalent to an extension allowing only the
+   uncompressed point format.
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 16]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+          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:
+
+   The server constructs an appropriate certificate chain and conveys it
+   to the client in the Certificate message.  If the client has used a
+   Supported Elliptic Curves Extension, the public key in the server's
+   certificate MUST respect the client's choice of elliptic curves; in
+   particular, the public key MUST employ a named curve (not the same
+   curve as an explicit curve) unless the client has indicated support
+   for explicit curves of the appropriate type.  If the client has used
+   a Supported Point Formats Extension, both the server's public key
+   point and (in the case of an explicit curve) the curve's base point
+   MUST respect the client's choice of point formats.  (A server that
+   cannot satisfy these requirements must not choose an ECC cipher suite
+   in its ServerHello message.)
+
+   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.
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 17]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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), reserved(4 .. 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.
+
+   Values 248 through 255 are reserved for private use.
+
+        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>;
+        } ECPoint;
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 18]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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].  This byte string may represent an elliptic curve point
+      in uncompressed, hybrid, or compressed format; it MUST conform to
+      what the client has requested through a Supported Point Formats
+      Extension if this extension was used.
+
+
+        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;
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 19]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   curve_type:  This identifies the type of the elliptic curve domain
+      parameters.
+
+   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 (either Fp or F2^m).
+
+   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;
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 20]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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;
+
+
+          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:
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 21]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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(??),
+            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 [14] 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 a suitable certificate for use
+   with any of the requested methods, and decides whether or not to
+   proceed with client authentication.
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 22]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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 and has decided to proceed with
+   client authentication.  (Note that if the server has used a Supported
+   Point Formats Extension, a certificate can only be considered
+   suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and
+   ECDSA_fixed_ECDH authentication methods if the public key point
+   specified in it respects the server's choice of point formats.  If no
+   Supported Point Formats Extension has been used, a certificate can
+   only be considered suitable for use with these authentication methods
+   if the point is represented in uncompressed point format.)
+
+   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).
+
+
+          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.
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 23]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+                     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:
+
+   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 { implicit, explicit } PublicValueEncoding;
+
+   implicit, explicit:  For ECC cipher suites, this indicates whether
+      the client's ECDH public key is in the client's certificate
+      ("implicit") or is provided, as an ephemeral ECDH public key, in
+      the ClientKeyExchange message ("explicit").  (This is "explicit"
+      in ECC cipher suites except when the client uses the
+      ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
+      mechanism.)
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 24]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+        struct {
+            select (PublicValueEncoding) {
+                case implicit: struct { };
+                case explicit: ECPoint ecdh_Yc;
+            } ecdh_public;
+        } ClientECDiffieHellmanPublic;
+
+   ecdh_Yc:  Contains the client's ephemeral ECDH public key as a byte
+      string ECPoint.point, which may represent an elliptic curve point
+      in uncompressed, hybrid, or compressed format.  Here the format
+      MUST conform to what the server has requested through a Supported
+      Point Formats Extension if this extension was used, and MUST be
+      uncompressed if this extension was not used.
+
+
+        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
+   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.
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 25]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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.
+
+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]
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 26]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   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] block type 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 27]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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
+
+
+   [[ EDITOR: The actual cipher suite numbers will be assigned when this
+   draft progresses to RFC. ]]
+
+   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 [15].
+
+   Server implementations SHOULD support all of the following cipher
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 28]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   suites, and client implementations SHOULD support at least one of
+   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
+   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
+   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
+   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 29]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+7.  Security Considerations
+
+   This document is based on [2], [5], [6] and [15].  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 Table 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 October 9, 2005               [Page 30]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+8.  Acknowledgments
+
+   The authors wish to thank Bill Anderson and Tim Dierks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 31]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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]  Harper, G., Menezes, A., and S. Vanstone, "Public-Key
+         Cryptosystems with Very Small Key Lengths", Advances in
+         Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
+
+   [13]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+         Sizes", Journal of Cryptology 14 (2001) 255-293,
+         <http://www.cryptosavvy.com/>.
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 32]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   [14]  Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
+         Version 3.0", November 1996,
+         <http://wp.netscape.com/eng/ssl3/draft302.txt>.
+
+   [15]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+         Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+
+Authors' Addresses
+
+   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
+
+
+   Simon Blake-Wilson
+   Basic Commerce & Industries, Inc.
+   96 Spandia Ave
+   Unit 606
+   Toronto, ON  M6G 2T6
+   CA
+
+   Phone: +1 416 214 5961
+   Email: sblakewilson@bcisse.com
+
+
+   Bodo Moeller
+   University of Calgary
+   Dept of Math & Stats
+   2500 University Dr NW
+   Calgary, AB  T2N 1N4
+   CA
+
+   Phone: +1 403 220 5735
+   Email: bodo@openssl.org
+
+
+   Chris Hawk
+   Corriente Networks
+
+   Email: chris@corriente.net
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 33]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+   Nelson Bolyard
+
+   Email: nelson@bolyard.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta, et al.            Expires October 9, 2005               [Page 34]
+
+Internet-Draft          ECC Cipher Suites for TLS             April 2005
+
+
+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 (2005).  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 October 9, 2005               [Page 35]
+
+