Transport Layer Security
TLS Working Group                         T. Dierks                                     Simon Blake-Wilson
INTERNET-DRAFT                               Consensus Development Corp.
Expires September, 1998                                      B. Anderson                                                Tim Dierks
Expires: September 14, 2001                                   Chris Hawk
                                                          Certicom Corp.
                                                           15 March 13, 1998 2001

                       ECC Cipher Suites For for TLS
                       draft-ietf-tls-ecc-00.txt

1.
                      <draft-ietf-tls-ecc-01.txt>

                          Status of this Memo

 This document is an Internet-Draft. Internet-Draft and is in full conformance with all
 provisions of Section 10 of RFC2026. 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 made obsolete 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 "work in progress.

   To learn the progress."

 The list of current status Internet-Drafts may be found at
 http://www.ietf.org/ietf/1id-abstracts.txt

 The list of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet Drafts Internet-Draft Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

2.  Introduction may be found at
 http://www.ietf.org/shadow.html.

                               Abstract

 This document describes additions to TLS to support the Elliptic Curve Cryptosystem
 Cryptography (ECC).  The document assumes that the reader is
   familiar with the TLS protocol.

   The document In particular it defines cipher suites new key exchange
 algorithms which use the Elliptic Curve
   Encryption Scheme (ECES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme
   with Appendix (ECNRA),
 (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme
 (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key
   Agreement (ECMQV) it defines how to perform client authentication with ECDSA
 and ECDH.

 The key establishment algorithms.  References words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to these
   algorithms can be found interpreted as described in section 13.

3. RFC 2119 [MUST].

 Please send comments on this document to the TLS mailing list.

                          Table of Contents

  1.     Status of this Memo ........................................ 1
   2.    Introduction ............................................... 1
   3.     Table of Contents .......................................... 2
   4.     Rationale .................................................. ................................................. 2
   5.
  2.    Elliptic Curve Key Establishment Methods ................... 3
   6.     Key Establishment Operation ................................ Exchange Algorithms ....................... 4
  2.1.  ECDH_ECDSA ................................................... 5
   6.1.   ECES_ECDSA .................................................
  2.2.  ECDH_ECDSA_EXPORT ............................................ 5
  2.3.  ECDH_RSA ..................................................... 6
   6.2.   ECES_ECNRA .................................................
  2.4.  ECDH_RSA_EXPORT .............................................. 6
   6.3.   ECDHE_ECDSA ................................................
  2.5.  ECDH_anon .................................................... 6
   6.4.   ECDHE_ECDSA_EXPORT ......................................... 7
   6.5.   ECDHE_ECNRA ................................................ 7
   6.6.   ECDHE_ECNRA_EXPORT .........................................
  2.6.  ECDH_anon_EXPORT ............................................. 6
  3.    ECC Client Authentication .................................... 7
   6.7.   ECDH_ECDSA .................................................
  3.1.  ECDSA_sign ................................................... 7
   6.8.   ECDH_ECNRA ................................................. 8
   6.9.   ECMQV_ECDSA ................................................
  3.2.  ECDSA_fixed_ECDH ............................................. 8
   6.10.  ECMQV_ECNRA ................................................ 9
   6.11.  ECDH_anon .................................................. 9
   6.12.  ECDH_anon_EXPORT ........................................... 9
   7.     Client Certification .......................................
  3.3.  RSA_fixed_ECDH ............................................... 9
   8.
  4.    Data Structures ........................................... and Computations ............................. 9
  4.1.  Server Certificate .......................................... 10
   8.1.
  4.2.  Server Key Exchange ....................................... 10
   8.2. ......................................... 11
  4.3.  Certificate Request ....................................... 13
   8.3. ......................................... 15
  4.4.  Client Certificate .......................................... 15
  4.5.  Client Key Exchange ....................................... 14
   8.4. ......................................... 16
  4.6.  Certificate Verify ........................................ 15
   9.     Elliptic Curve Certificates ............................... 15
   10.    Cipher Suites ............................................. 16
   11.    Elliptic Curve Cryptography Definitions ................... 17
   12.    Recommended .......................................... 18
  4.7.  Computing the Master Secret ................................. 19
  5.    Cipher Suites ................................. 17
   13.    References ................................................ 17
   14. ............................................... 19
  6.    Security Considerations ................................... 18
   15. ..................................... 20
  7.    Intellectual Property Rights ................................ 20
  8.    Acknowledgments ............................................. 21
  9.    References .................................................. 21
  10.   Authors' Addresses ........................................ 18

4.  Rationale

   Several design goals drove our choice of key establishment
   algorithms: .......................................... 22

1. A desire  Introduction

This document describes additions to replicate all of the functionality and operating
       modes found in the current TLS cipher suites based on integer
       factorization and discret log cryptographic algorithms.

    2. While we wished to define cipher suites which use export-strength
       cryptography, we did not want to define any cipher suites which
       would require certificates with export-strength keys; thus,
       exportable cipher suites are only defined for those support Elliptic Curve
Cryptography (ECC). In particular, it defines:

- new key
       establishment mechanisms exchange algorithms which use the certificate key for
       authentication rather than for key establishment.

   These criteria for key establishment algorithms, when combined with a
   number of symmetric algorithms, led to a large number of possible
   cipher suites. This is problematic in that it could lead to a lack of
   interoperability due to implementors supporting different subsets of Elliptic Curve Digital
  Signature Algorithm (ECDSA), and the available cipher suites. Elliptic Curve Diffie-Hellman
  Key Agreement Scheme (ECDH); and

- new client authentication methods which use ECDSA and ECDH.

In order to alleviate this, we have
   indicated two enable the use of these features within TLS, the total cipher suites as recommended (see section
   12).  Unless there are specific reasons document
defines enhanced data structures to choose other cipher
   suites, implementors should implement convey the recommended suites first.

5.  Elliptic Curve Key Establishment Methods

   Key establishment is the terminology used in ISO standards to refer
   to information that the methods of establishing a shared key between two or more
   parties.  Within key establishment there are two classifications:
   The operation is called key transport when only one party contributes
mechanisms need to exchange, the generation of computational procedures involved in
the shared key.  The operation is called key
   agreement when 2 or more parties contribute to the generation of the
   shared key. For mechanisms, and new cipher suites based on the purposes
mechanisms.

Use of this definition, the key in question
   is the premaster secret: ECC within TLS uses the master secret generation
   process to ensure that may provide both parties contribute bandwidth and computational
savings compared to other public-key cryptographic techniques.
Furthermore, the eventual master
   secret.

   The cipher suites defined here use efficiencies provided by ECC may increase as security
requirements increase based on Moore's law - this is illustrated by the
following table, based on [LEN], which gives approximate comparable key establishment
   methods:

   ECES_ECDSA           Elliptic-curve encryption is used
sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based
on the key
                        transport; the server's certificate is signed
                        using ECDSA.

   ECES_ECNRA           Elliptic-curve encryption is used for running times of the best algorithms known today.

              Symmetric    |  ECC    |  DH/DSA/RSA
                 80        |  163    |  1024
                128        |  283    |  3072
                192        |  409    |  7680
                256        |  571    |  15360

             Table 1: Comparable key
                        transport; sizes (in bits)

The savings that ECC may offer are likely to become increasingly
desirable with the server's certificate is signed
                        using ECNRA.

   ECDHE_ECDSA          Ephemeral elliptic-curve Diffie-Hellman is used widespread use of TLS by wireless devices -
discussed, for example, in [TLS-EXT].

This document assumes the key agreement; the server signs the
                        parameters reader is familiar with an ECDSA key both ECC and TLS. ECC
is
                        authenticated with a certificate signed with
                        ECDSA.

   ECDHE_ECDSA_EXPORT   Ephemeral elliptic-curve Diffie-Hellman described in
                        export strength ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE
1363 [IEEE1363], and SEC 1 [SEC1]. TLS is used for the key agreement; described in RFC 2246 [TLS].

The choice of mechanisms included in this document was motivated by a
desire to provide mechanisms which are secure, which are as efficient
as possible, and which are capable of replicating all of the server signs
functionality and operating modes found in the parameters with an ECDSA
                        key existing TLS mechanisms
based on integer factorization and is authenticated with discrete logarithm cryptographic
systems. TLS includes a certificate
                        signed substantial variety of functionality and
operating modes in consideration of the variety of applications with ECDSA.

   ECDHE_ECNRA          Ephemeral elliptic-curve Diffie-Hellman
which TLS is used
                        for used.

The desire described above led to the key agreement; inclusion of a substantial number
of ECC-based mechanisms. In order to encourage interoperability, a
small subset of the server signs mechanisms are identified as "recommended" - these
mechanisms are capable of meeting the
                        parameters with an ECNRA key requirements of many
applications and is
                        authenticated with a certificate signed with
                        ECNRA.

   ECDHE_ECNRA_EXPORT   Ephemeral elliptic-curve Diffie-Hellman they should therefore be used unless an application
profile of this document states otherwise, or unless in a particular
environment considerations such as export strength regulations mandate
otherwise.

The remainder of this document is used organized as follows. Section 2
specifies key exchange algorithms for TLS using ECC. Section 3
specifies how client authentication is performed using ECC. Section 4
describes the key agreement; TLS-specific data structures and computations involved in
the server signs operation of the parameters with an ECNRA
                        key and is authenticated with a certificate
                        signed with ECNRA.

   ECDH_ECDSA           Fixed elliptic-curve Diffie-Hellman is used for ECC mechanisms. Section 5 defines cipher suites
based on the ECC key agreement; exchange algorithms. Sections 6-8 discuss security
considerations, intellectual property rights, and acknowledgements
respectively. Section 9 supplies references cited elsewhere in the server's certificate is
                        signed with ECDSA.

   ECDH_ECNRA           Fixed elliptic-curve Diffie-Hellman is used for
document, and Section 10 gives the authors' contact details.

2.  Elliptic Curve Key Exchange Algorithms

This document defines six new key agreement; the server's certificate is
                        signed with ECNRA.

   ECMQV_ECDSA          Ephemeral elliptic-curve MQV is used exchange algorithms based on ECC for key
                        agreement and authentication;
use within TLS.

The table below summarizes the server is
                        authenticated new key exchange algorithms.

   Key
   Exchange
   Algorithm          Description                        Key size limit

   ECDH_ECDSA         ECDH with a certificate signed ECDSA signatures         None
   ECDH_ECDSA_EXPORT  ECDH with
                        ECDSA.

   ECMQV_ECNRA          Ephemeral elliptic-curve MQV is used for key
                        agreement and authentication; the server is
                        authenticated ECDSA signatures         ECDH=163 bits,
                                                         ECDSA=none
   ECDH_RSA           ECDH with a certificate signed RSA signatures           None
   ECDH_RSA_EXPORT    ECDH with
                        ECNRA. RSA signatures           ECDH=163 bits,
                                                         RSA = none
   ECDH_anon          Anonymous elliptic-curve Diffie-Hellman is used
                        for the key agreement. ECDH, no signatures      None
   ECDH_anon_EXPORT   Anonymous elliptic-curve Diffie-Hellman in
                        export strength is used for the key agreement. ECDH, no signatures      ECDH=163 bits

                     Table 2: Key establishment mechanisms which indicate exchange algorithms

Note that they are for export
   strength should use an ECC key for the key agreement exchange algorithms marked "anon" do not provide
authentication of no more than
   113 bits. A 113-bit ECC key provides security that is roughly
   equivalent to a 512-bit RSA the server or the client, and, like other "anon" TLS
key and is expected to exchange algorithms, may be eligible for
   export.  The following table relates ECC key sizes subject to RSA key sizes man-in-the-middle attacks.
Implementations of equivalent security.  These these algorithms SHOULD provide authentication by
other means.

The remainder of this section describes these key sizes are considered equivalent exchange algorithms
in
   terms of work factor required to recover the private detail. For each key using
   currently known fastest methods for solving exchange algorithm, this involves specification
of the underlying
   mathematical problems contents of ECC and RSA.

               ECC         RSA      Time the handshake messages related to break (MIPS-years)
             ________   _________   __________________________
             106 bits    512 bits   1E4 MY
             132 bits    768 bits   1E8 MY
             160 bits   1024 bits   1E11 MY
             191 bits   1536 bits   1E14 MY
             211 bits   2048 bits   1E20 MY

          Table 1: ECC and RSA key sizes for equivalent security

6.  Key Establishment Operation

   The TLS exchange -
server certificate, server key establishment protocol involves this message exchange:

           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
               * exchange, client certificate, and client
key exchange - Message is not sent under some conditions

   Of these messages, as well as specification of the ones computations involved in
the key establishment itself
   are the server's Certificate message, the ServerKeyExchange, the
   client's Certificate message, and calculation of the ClientKeyExchange.

   In order master secret.

2.1.  ECDH_ECDSA

ECDH is used to specify the ECC cipher suites, we must specify compute the
   following elements for each master secret. The server is authenticated
via a certificate containing an ECDH public key establishment algorithm: signed with ECDSA.

Specifically this key exchange algorithm MUST proceed as follows:

- The format of server provides a static ECDH public key in the server's certificate. server
  certificate message using the format described in Section 4.1. The
  certificate is signed using ECDSA.

- The format of the server key exchange message is not sent.

-  For methods Unless client authentication using ECDH is performed as specified in which
  Sections 3.2 and 3.3, the client's certificate can participate client provides an ephemeral ECDH public
  key in the client key agreement, exchange message using the format of described in
  Section 4.5. In this case, the client's client certificate and the
       criteria for deciding if this certificate
  verify message are not sent unless client authentication is eligible to
       participate performed
  using ECDSA as specified in the key agreement. Section 3.1, or another signature
  algorithm.

-  The format of If client authentication using ECDH is performed, the client provides
  a static ECDH public key exchange message

    -  How to arrive at in the premaster secret given all client certificate message using the preceding
       information.

   Several different key establishment modes are available.
  format described in Section 4.4. In order to
   allow full negotiation of supported algorithms, this case an empty client key
  exchange message is sent using the signature
   algorithm used for format described in Section 4.5, and
  the server's X.509 certificate verify message is encoded into not sent.

- The client and server compute the
   cipher suite for those master secret using their ECDH key establishment mechanisms where no
   signature algorithm is used;
  pairs as specified in Section 4.7.

ECDH computations for those this key establishments which
   utilize signature algorithms, the certificate signature exchange algorithm is
   expected are performed
according to be IEEE 1363 [IEEE1363] - using the same as ECKAS-DH1 scheme with the algorithm used in
ECSVDP-DH secret value derivation primitive, and the KDF1 key
   establishment.

6.1.  ECES_ECDSA

   In ECES_ECDSA,
derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
performed according to ANSI X9.62 [ANSIX962] using the hash function
SHA-1 [FIPS180-1].

2.2.  ECDH_ECDSA_EXPORT

Export-strength ECDH is used to compute the master secret. The server sends
is authenticated via a certificate with containing an ECES-capable ECDH public key in it.  The server's certificate should be signed
with ECDSA.  A ServerKeyExchange message is not sent because the server's
   certificate contains all the necessary keying information for the
   client to complete the

This key establishment.

   The client's certificate is not involved exchange algorithm MUST proceed in the same way as ECDH_ECDSA,
except that the key establishment size for
   this method, although the client can still be authenticated via the
   normal mechanism.

   The client generates a 48 byte premaster secret, encrypts it using
   ECES using ECDH public keys is constrained to 163
bits or less. Here the key size of an elliptic curve public key from the server's certificate, and sends it refers
to the server in size of the ClientKeyExchange message (see section 8.3).

   This premaster secret is decrypted by underlying finite field over which the server and both sides use
   it elliptic
curve is defined.

2.3.  ECDH_RSA

ECDH is used to generate compute the master secret for this TLS session.

6.2.  ECES_ECNRA

   ECES_ECNRA secret. The server is authenticated
via a certificate containing an ECDH public key signed with RSA.

This key exchange MUST proceed in the same way as ECES_ECDSA ECDH_ECDSA, except for the fact
that the server's certificate is signed by its CA with ECNRA.

6.3.  ECDHE_ECDSA

   In ECDHE_ECDSA, RSA.

2.4.  ECDH_RSA_EXPORT

Export-strength ECDH is used to compute the server's master secret. The server
is authenticated via a certificate has containing an ECDSA ECDH public key and is, in
   turn, signed by its CA
with ECDSA. The ServerKeyExchange message
   contains an ephemeral ECDH RSA.

This key and a specification of exchange algorithm MUST proceed in the curve same way as ECDH_RSA,
except that the key size for
   this key. (see section 8.1).  These parameters are signed with ECDH public keys is constrained to be 163
bits or less.

2.5.  ECDH_anon

Anonymous ECDH is used to compute the
   server's authenticated ECDSA key. master secret.

Specifically this key exchange algorithm MUST proceed as follows:

- The client's server certificate message is not involved sent.

- The server provides an ephemeral ECDH public key in the server key establishment for
   this method, although the client can still be authenticated via
  exchange message using the
   normal mechanism. format described in Section 4.2.

- The client should verify the signature on the ServerKeyExchange certificate message and generate is not sent.

- The client provides an ephemeral ECDH public key on the same curve as in the server's
   ephemeral key. The client encodes the public half of that key into
   the ClientKeyExchange
  exchange message and sends it to using the server. format described in Section 4.5.

- The client and server perform an ECDH key agreement using their
   private keys and compute the public keys they have sent to each other. The
   resultant shared master secret is the premaster secret.

6.4.  ECDHE_ECDSA_EXPORT

   ECDHE_ECDSA_EXPORT is the same using their ECDH
  key pairs as ECDHE_ECDSA except specified in Section 4.7.

ECDH computations for this key exchange algorithm are performed
according to IEEE 1363 [IEEE1363] - using the fact
   that the curve used for ECKAS-DH1 scheme with the server's ephemeral ECDH key should be no
   longer than 113 bits.  Because
ECSVDP-DH secret value derivation primitive, and the server's certified KDF1 key
derivation primitive using SHA-1 [FIPS180-1].

2.6.  ECDH_anon_EXPORT

Export-strength, anonymous ECDH is only used for authentication, its length is unrestricted.

6.5.  ECDHE_ECNRA

   ECDHE_ECNRA is the same as ECDHE_ECDSA except for the fact that to compute the
   server's public key is an ECNRA master secret.
This key and the server's certificate is
   signed by its CA with ECNRA.

6.6.  ECDHE_ECNRA_EXPORT

   ECDHE_ECNRA_EXPORT is exchange algorithm MUST proceed in the same way as ECDHE_ECNRA ECDH_anon,
except for the fact that the curve used for the server's ephemeral ECDH key should be no
   longer than 113 bits.  Because the server's certified key is only
   used size for authentication, its length is unrestricted.

6.7.  ECDH_ECDSA

   In ECDH_ECDSA, the server's certificate contains an ECDH public key.
   This certificate keys is signed by constrained to 163
bits or less.

3.  ECC Client Authentication

This document defines three new ECC-based client authentication methods
- ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH.

To encourage interoperability, implementations SHOULD support
ECDSA_fixed_ECDH. Implementations MAY support any of the server's CA using ECDSA. other client
authentication methods.

The
   ServerKeyExchange message is not sent because the server's
   certificate contains all the necessary keying remainder of this section specifies these ECC-based client
authentication methods. The following information is provided for each
method: which key exchange algorithms the
   client method may be used with, what
constraints apply to complete the key establishment.

   If the server requests client authentication method, and includes the
   ecdsa_fixed_dh or ecnra_fixed_dh client formats of the certificate types (see
   section 8.2)
request, client certificate, client key exchange, and the certificate
verify messages.

3.1.  ECDSA_sign

The client has supplies a certificate which contains containing an ECDH
   key on the same curve as the server's ECDSA public key, and this
authenticates itself by signing the certificate verify message with its
ECDSA key pair.

This client authentication method MUST proceed as follows.

Applicable key exchange algorithms:

- This client authentication method is otherwise eligible to be used for client
   authentication, then use with all the client's certified public
  non-anonymous ECC-based key is used exchange algorithms specified in
   conjunction with Section
  2, and all the server's public key to do an ECDH existing non-anonymous TLS key agreement;
   the resultant shared secret is the premaster key. exchange algorithms
  specified in [TLS].

Restrictions:

- In order to perform this situation, method, the client key exchange message is empty when sent and must possess a certified
  ECDSA public key.

Message exchange:

- The server requests use of the client
   CertificateVerify ECDSA_sign method by sending a
  certificate request message is not sent, as both containing the client and value "ecdsa_sign" using
  the
   server are authenticated by their ability to arrive at format described in Section 4.3. When the same
   premaster secret.

   If client certification receives this
  request, it checks that it possesses an appropriate certificate and
  that it is not requested or if willing to proceed.

- If the client does not
   have a proceeds, it sends its certificate with a suitable ECDH containing its ECDSA
  public key, key in the client can
   generate an ephemeral key on certificate message using the same curve as format
  described in Section 4.4. It signs the server's public
   key.  This handshake messages exchanged
  so far with its ECDSA key is encoded into the ClientKeyExchange message (see
   section 8.3) pair and used in conjunction with conveys the server's key resulting signature to
   complete
  the ECDH key agreement, yielding server in the premaster secret.

6.8.  ECDH_ECNRA

   ECDH_ECNRA is certificate verify message using the same as ECDH_ECDSA except for format
  specified in Section 4.6.

- (If the fact that client does not proceed, it may perform client authentication
  using another method suggested by the server in the
   server's certificate is signed by its CA with ECNRA.

6.9.  ECMQV_ECDSA

   In ECMQV_ECDSA,
  request message in which case the server's client certificate contains an ECMQV key and is
   signed by the server's CA
  certificate verify message are sent in accordance with ECDSA. The server then generates an
   temporary key pair and sends the public half of selected
  method, or it may proceed with the temporary key in
   the ServerKeyExchange message (see section 8.1).

   If the server requests exchange without client
  authentication and includes - in which case the
   ecdsa_mqv or ecnra_mqv client certificate types (see section 8.2) and certificate
  verify messages are not sent.)

ECDSA computations for this client authentication method are performed
according to ANSI X9.62 [ANSIX962] using the hash function SHA-1
[FIPS180-1].

3.2.  ECDSA_fixed_ECDH

The client has a supplies an ECDSA-signed certificate which contains containing an ECMQV ECDH
public key on using the same elliptic curve domain parameters as the
server's ECDH public key, and this certificate is otherwise
   eligible to be used for key. The client authentication, then authenticates itself by computing
the client should
   send that certificate, then generate a temporary key master secret and send the
   public half of that key in finished message. (This achieves
authentication because these computations can only be performed by a
party possessing the ClientKeyExchange message (see section
   8.3).  The client and server then perform an MQV key agreement using
   their private keys and their peer's public keys (for each party, both
   the certified and temporary key pairs are used).  The resultant
   shared secret is corresponding to one of the premaster secret.  The ECDH
public keys exchanged.)

This client CertificateVerify
   message is not sent, authentication method MUST proceed as both the client and follows.

Applicable key exchange algorithms:

- This method is eligible for use with all the server are
   authenticated by their ability non-anonymous ECC-based
  key exchange algorithms specified in Section 2.

Restrictions:

- In order to arrive at the same premaster
   secret.

   If perform this client certification is not requested or if authentication method, the client does not
   have a
  must possess an ECDSA-signed certificate with a suitable ECMQV containing an ECDH public key, the client
   should generate two temporary
  key pairs on using the same elliptic curve domain parameters as the
   server's public key.  The ECDH
  public halves of these temporary key pairs
   are encoded into the ClientKeyExchange message.  One key pair is the
   usual temporary key used for MQV and supplied by the other takes server in the place server certificate message.

Message exchange:

- The server requests use of the
   certified key.  Each side performs an MQV key agreement using the
   peer's public keys and its own private keys, yielding ECDSA_fixed_ECDH method by sending a
  certificate request message containing the premaster
   secret.

6.10.  ECMQV_ECNRA

   ECMQV_ECNRA is value "ecdsa_fixed_ecdh"
  using the same as ECMQV_ECDSA except for format described in Section 4.3. When the fact client receives
  this request, it checks that the
   server's certificate is signed by its CA with ECNRA.

6.11.  ECDH_anon

   In ECDH_anon, it possesses an anonymous Elliptic-Curve Diffie-Hellman operation is
   used to arrive at the premaster secret.  In this case, the server is
   not authenticated appropriate certificate
  and may not request that the client authenticate
   itself.  The server's Certificate message it is not sent. The
   ServerKeyExchange message contains willing to proceed.

- If the specification of a curve and a
   Diffie-Hellman public key (see section 8.1).  The client responds
   with a ClientKeyExchange message proceeds, it sends its certificate containing a Diffie-Hellman its ECDH
  public key on the same curve; in the premaster secret is client certificate message using the shared secret
   resulting from format
  described in Section 4.4. It sends an Elliptic Curve Diffie-Hellman empty client key agreement with
   these keys.

6.12.  ECDH_anon_EXPORT

   ECDH_anon_EXPORT is the same as ECDH_anon except for exchange
  message using the fact that format described in Section 4.5. It does not send
  the curve used for certificate verify message. It uses its static ECDH key pair,
  along with the server's ephemeral ECDH key should be no
   longer than 113 bits.

7.  Client Certification

   Six new client certificate types have been added: ecdsa_sign,
   ecnra_sign, ecdsa_fixed_dh, ecnra_fixed_dh, ecdsa_mqv, and ecnra_mqv.
   As noted above, public key) when computing the fixed_dh master
  secret and mqv types are used in key
   establishment methods which allow the client's certified key to
   participate in key agreement.  In these cases, finished message.

- (If the CertificateVerify
   message is client does not sent; the client's ability to arrive at the same
   premaster secret as proceed, it may perform client authentication
  using another method suggested by the server demonstrates its control over the
   private half of the certified public key.

   One of these certificates is eligible for use in the key agreement
   operation if certificate
  request message, or it has a may proceed with the key exchange without
  client authentication - in which can be used with that algorithm.
   Because elliptic curve keys have case the same mathematical properties client certificate and
  certificate verify messages are not sent.)

ECDH computations for
   all the algorithms discussed in this specification, a certificate
   could have a key which was authorized for use in any of several
   algorithms or for only a particular algorithm.  In addition exchange algorithm are performed
according to the
   key's eligibility, it must be defined IEEE 1363 [IEEE1363] - using the same curve parameters
   as the server's key to be used in a operation ECKAS-DH1 scheme with it.  Of course, the use of a certificate is always subject to any
ECSVDP-DH secret value derivation primitive, and all policy
   constraints placed on it.

   In these certificates, the ecdsa or ecnra refers to the algorithm
   which the CA uses KDF1 key
derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
performed according to sign ANSI X9.62 [ANSIX962] using the client's certificate. hash function
SHA-1 [FIPS180-1].

3.3.  RSA_fixed_ECDH

The ecdsa_sign and ecnra_sign client supplies an RSA-signed certificate types are used in other containing an ECDH
public key
   establishment methods and in cases where using the same elliptic curve domain parameters as the
server's ECDH public key. The client authenticates itself by computing
the master secret and the finished message. (This achieves
authentication because these computations can not or
   chooses not to supply only be performed by a suitable certificate
party possessing the private key corresponding to participate in one of the above methods.  In these cases, the ECDH
public keys exchanged.)

This client must send a
   CertificateVerify message to demonstrate its control of authentication method MUST proceed in the private
   half key of same manner as
the certified key pair.  (See section 8.4).

   Certificates requested with ECDSA_fixed_ECDH method, except that the ecdsa_sign ClientCertificateType client's certificate must
   include an ECDSA public key and
be signed by the CA with ECDSA;
   ecnra_sign certificates must include an ECNRA key RSA, and be signed with
   ECNRA.

   With all key establishment methods, it is permissible to request a
   client certificate using a different algorithm than the one used for the server's certificate; for example, a server doing requests use of the method by
sending a ECDHE_ECDSA
   or ECMQV_ECDSA key establishment could still certificate request an ECNRA client
   certificate.

8. message containing the value
"rsa_fixed_ecdh".

4.  Data Structures

   Here the descriptions of and Computations

This section specifies the data structures exchanged are given. and computations used by the
ECC-based mechanisms specified in Sections 2 and 3. The presentation
language used here is the same as that used in the TLS
   specification. RFC 2246 [TLS]. Because
these specifications extend the TLS protocol specification, these
descriptions should be merged with those in TLS and in any other
specifications which extend TLS. This means that enum types may not
specify all the possible values and structures with multiple formats
chosen with a select() clause may not indicate all the possible cases.

8.1.

4.1.  Server Certificate

This message is sent in the following key exchange algorithms:

All the non-anonymous ECC-based key exchange algorithms specified in
Section 2.

Meaning of this message:

This message is used to authentically convey the server's static public
key to the client. The appropriate certificate types are given in the
following table.

       Key Exchange Algorithm  Certificate Type

       ECDH_ECDSA              ECC public key; the certificate must
                               allow the key to be used for key
                               agreement. The certificate must be
                               signed with ECDSA.

       ECDH_ECDSA_EXPORT       ECC public key which can be used for key
                               agreement; key size must be 163 bits or
                               less. Certificate must be signed with
                               ECDSA.

       ECDH_RSA                ECC public key which can be used for key
                               agreement. Certificate must be signed
                               with RSA.

       ECDH_RSA_EXPORT         ECC public key which can be used for key
                               agreement; key size must be 163 bits or
                               less. Certificate must be signed with
                               RSA.

                       Table 3: Server certificate types

[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
X.509 certificates. Servers SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
[FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same
identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
usage extension may be used to further delimit the use of the key. When
a key usage extension is present, the "keyAgreement" bit MUST be set
for ECDH certificates.

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.

Actions of the receiver:

The client validates the certificate chain, extracts the server's
public key, and checks that the key is of the correct type for the key
exchange algorithm.

4.2.  Server Key Exchange

This messages message is sent in the following key establishment methods:

           ECDHE_ECDSA
           ECDHE_ECDSA_EXPORT
           ECDHE_ECNRA
           ECDHE_ECNRA_EXPORT
           ECMQV_ECDSA
           ECMQV_ECNRA
           ECDH_anon
           ECDH_anon_EXPORT

   It can contain exchange algorithms:

Both the anonymous ECC-based key exchange algorithms specified in
Section 2.

Meaning of this message:

This message is used to convey the server's ephemeral ECDH public key
(and the corresponding elliptic curve Diffie-Hellman keys, either signed or
   unsigned, or MQV parameters. domain parameters) to the client.

Structure of this message:

The TLS ServerKeyExchange message is extended as follows.

     enum { ec_eces,
              ec_diffie_hellman,
              ec_menezes_qu_vanstone ec_diffie_hellman } KeyExchangeAlgorithm;

ec_diffie_hellman
Indicates the ServerKeyExchange message is to contain an ECDH public
key.

     enum { ec_prime_p explicit_prime (1),
              ec_characteristic_two explicit_char2 (2),
            named_curve (3), (255) } ECFieldID;

       enum { ec_basis_onb, ec_basis_trinomial,
              ec_basis_pentanomial } ECBasisType; ECCurveType;

explicit_prime
Indicates the elliptic curve domain parameters will be conveyed
verbosely, and that the underlying finite field is a prime field.

explicit_char2
Indicates the elliptic curve domain parameters will be conveyed
verbosely, and that the underlying finite field is a characteristic 2
field.

named_curve
Indicates that a named curve will be used. The use of this option is
strongly recommended.

     struct {
         opaque a <1..2^8-1>;
         opaque b <1..2^8-1>;
         opaque seed <0..2^8-1>;
     } ECCurve;

a, b: b
These parameters specify the coefficients of the elliptic curve. Each
value shall be contains the octet byte string representation of a field element
following the conversion routine in [X9.62], section
   4.3.1.

   seed: 4.3.3.

seed
This is an optional parameter used to derive the coefficients of a
randomly generated elliptic curve.

     struct {
         opaque point <1..2^8-1>;
     } ECPoint;

   point:

point
This is the octet byte string representation of an elliptic curve point
following the conversion routine in [X9.62], section 4.4.2.a.
   The 4.3.6.

     enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

ec_basis_trinomial
Indicates representation format is defined following of a characteristic two field using a
trinomial basis.

ec_basis_pentanomial
Indicates representation of a characteristic two field using a
pentanomial basis.

     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), (255)
     } NamedCurve;

sect163k1, etc
Indicates use of the definition corresponding recommended curve specified in
   [X9.62], section 4.4. SEC 2
[SEC2]. Note that many of these curves are also recommended in ANSI
X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2].

     struct {
           ECFieldID   field;
         ECCurveType    curve_type;
         select (field) (curve_type) {
             case ec_prime_p: 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 ec_characteristic_two: explicit_char2:
                 uint16      m;
                 ECBasisType basis;
                 select (basis) {
                     case ec_basis_onb:
                           struct { };
                       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;

   field:

curve_type
This identifies the finite field over which type of the elliptic curve
   is defined.

   prime_p: domain parameters.

prime_p
This is the odd prime defining the field Fp.

   m: This is the degree of the characteristic-two field F2^m.

   k: The exponent k for the trinomical 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.

   curve:

curve
Specifies the coefficients a and b of the elliptic curve E.

   base: The

base
Specifies the base point P G on the elliptic curve.

   order: The

order
Specifies the order n of the base point. The order of a point P is

cofactor
Specifies the
   smallest possible integer n such that nP = 0 (the point at infinity).

   cofactor: The integer 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-two 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.

namedcurve
Specifies a recommended set of elliptic curve domain parameters.

     struct {
         ECParameters    curve_params;
         ECPoint         public;
     } ServerECDHParams;

   curve_params: This specifies

curve_params
Specifies the elliptic curve on which domain parameters associated with the elliptic-curve
   Diffie-Hellman key agreement is to occur.

   public: The ephemeral
ECDH public key.

public key for the elliptic-curve Diffie-
   Hellman key agreement.

       struct {
           ECPoint         temp_public;
       } ServerMQVParams;

   temp_public:
The temporary MQV ephemeral ECDH public key; the curve on which the MQV
   operation will take place is specified by the server's certificate.

       enum { ec_dsa, ec_nra } SignatureAlgorithm;

       select (SignatureAlgorithm) {
           case ec_dsa:
               digitally-signed struct {
                   opaque sha_hash[20];
               };
           case ec_nra:
               digitally-signed struct {
                   opaque sha_hash[20];
               };
       } Signature; key.

     select (KeyExchangeAlgorithm) {
         case ec_diffie_hellman:
             ServerECDHParams    params;
             Signature           signed_params;
           case ec_menezes_qu_vanstone:
               ServerMQVParams     params;
     } ServerKeyExchange;

   Note: The anonymous case for Signature

params
Specifies the ECDH public key and associated domain parameters.

signed_params
This element is used empty for ECDH_anon and
   ECDH_anon_EXPORT all the key establishment methods: exchange algorithms specified in
this case, document.

Actions of the
   Signature element is empty.

8.2.  Certificate Request sender:

The only addition 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 [IEEE1363]. It conveys this information
to the client in the ServerKeyExchange message using the format defined
above.

Actions of the recipient:

The client retrieves the server's elliptic curve domain parameters and
ephemeral ECDH public key from the ServerKeyExchange message.

4.3.  Certificate Request

This message is six new types for sent when requesting the following client
authentication methods:

Any of the ECC-based client authentication methods specified in
Section 3.

Meaning of this message:

The server uses this message to indicate which client
   certificate. authentication
methods the server would like to use.

Structure of this message:

The TLS CertificateRequest message is extended as follows.

     enum {
           ecdsa_sign(5), ecnra_sign(6),
           ecdsa_fixed_dh(7), ecnra_fixed_dh(8),
           ecdsa_mqv (9), ecnra_mqv (10),
         ecdsa_sign (5), rsa_fixed_ecdh (6),
         ecdsa_fixed_ecdh(7), (255)
     } ClientCertificateType;

8.3.

ecdsa_sign, etc
Indicates that the server would like to use the corresponding client
authentication method specified in Section 3.

Actions of the sender:

The server decides which client authentication methods it would like to
use, and conveys this information to the client using the format
defined above.

Actions of the receiver:

The client determines whether it has an appropriate certificate for use
with any of the requested methods, and decides whether or not to
proceed with client authentication.

4.4. Client Key Exchange Certificate

This message is sent in all the following client authentication methods:

All the ECC-based client authentication methods specified in Section 3.

Meaning of this message:

This message is used to authentically convey the client's static public
key exchanges. It to the server. The appropriate certificate types are given in the
following table.

       Client Authentication   Certificate Type
       Method

       ECDSA_sign              ECC public key which can contain either an
   ECES encrypted secret, an ECDH be used for
                               signing.

       ECDSA_fixed_ECDH        ECC public key (for use in ECDHE or
   ECDH_anon which can be used for key establishment methods), an ECMQV temporary
                               agreement. Certificate must be signed
                               with ECDSA.

       RSA_fixed_ECDH          ECC public key,
   or two temporary keys key which can be used for key
                               agreement. Certificate must be signed
                               with RSA.

                       Table 4: Client certificate types

[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
X.509 certificates. Clients SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
[FIPS186-2], and SEC 2 [SEC2]. Note that - as with MQV when RSA - the client does not have same
identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
usage extension may be used to further delimit the use of the key. When
a suitable certificate. key usage extension is present, the "keyAgreement" bit MUST be set
for ECDH certificates, and the "digitalSignature" bit MUST be set for
ECDSA certificates.

Structure of this message:

       struct {
           select (PublicValueEncoding) {
               case implicit: struct { };
               case explicit: ECPoint  ecdh_Yc;
           } ecdh_public;
       } ClientECDiffieHellmanPublic;

   If

Identical to the TLS Certificate format.

Actions of the sender:

The client has sent a 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 is of the correct type for the
client authentication method.

4.5.  Client Key Exchange

This message is sent in the following key exchange algorithms:

All the ECC-based key exchange algorithms specified in Section 2. If
client authentication with an fixed ECDH key, is not being used, the
   PublicValueEncoding will be implicit and this message will be empty.
   Otherwise, ecdh_Yc will be
contains the client's ephemeral ECDH public value for key, otherwise the message
is empty.

Meaning of the message:

This message is used to convey ephemeral data relating to the Diffie-
   Hellman key agreement.
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.

     struct {
         select (PublicValueEncoding) (EphemeralPublicKey) {
             case implicit: yes: ECPoint  ecdh_Yc;
             case no:  struct { };
               case explicit: ECPoint  ecmqv;
         } ecmqv_public;
           ECPoint     ecmqv_temp; ecdh_public;
     } ClientECMQVPublic;

   If the client has sent a certificate with an MQV key, the
   PublicValueEncoding will be implicit and the ecmqv_public field will
   be empty; otherwise, ecmqv will contain ClientECDiffieHellmanPublic;

ecdh_Yc
Contains the client's MQV public
   value.  In either case, ecmqv_temp will contain the temporary public
   key for the MQV operation.

   In the explicit case, the cost of an additional key generation can be
   saved by generating only one ephemeral key and sending two copies:
   one in ecmqv and one in ecmqv_temp. ECDH public key.

     struct {
         select (KeyExchangeAlgorithm) {
             case ec_eces: EncryptedPreMasterSecret;
               case ec_diffie_hellman: ClientECDiffieHellmanPublic;
               case ec_menezes_qu_vanstone: ClientECMQVPublic;
         } exchange_keys;
     } ClientKeyExchange;

   In

Actions of the ECES case, sender:

The client selects an ephemeral ECDH public key corresponding to the premaster secret will be sent encrypted with
parameters it received from the server's public key. server according to the ECKAS-DH1
scheme from IEEE 1363 [IEEE1363]. It conveys this information to the
client in the ClientKeyExchange message using the format defined
above.

Actions of the recipient:

The standard TLS definition server retrieves the client's ephemeral ECDH public key from the
ServerKeyExchange message and checks that the public key represents a
point of
   EncryptedPreMasterSecret is suitable for this transmission.

8.4. the elliptic curve.

4.6.  Certificate Verify

This message is sent when in the following client has sent a certificate which did
   not participate in a Diffie-Hellman or Menezes-Qu-Vanstone key
   agreement.

   This type needs no new definition: authentication methods:

ECDSA_sign

Meaning of the CertificateVerify message:

This message contains an ECDSA signature on the handshake messages in
   TLS uses
order to authenticate the Signature type, which we have client to the server.

Structure of this message:

The TLS CertificateVerify message is extended for as follows.

     enum { ec_dsa } SignatureAlgorithm;

     select (SignatureAlgorithm) {
         case ec_dsa:
             digitally-signed struct {
                 opaque sha_hash[20];
             };
     } Signature;

In the CertificateVerify message, the signature field contains the
client's ECDSA and
   ECNRA (see section 8.1).

9.  Elliptic Curve Certificates

   All X.509 certificates must be in compliance with signature on the PKIX profile of handshake messages exchanged so far.
According to [ANSIX962], the X.509 standard [PKIX].  Elliptic curve keys should be encoded signature consists of a pair of integers r
and s. These integers are both converted into X.509 certificates byte strings of the same
length as the curve order n using the conversion routine specified in [PKIX-ECDSA].  However, this
   document currently only specifies formats for ECDSA keys and
   signatures.

   When this document refers to a certificate with an ECDSA, ECNRA,
   ECES, ECDH, or ECMQV key, it means a public key which is capable
Section 4.3.1 of
   performing a particular algorithm [ANSIX962], the two byte strings are concatenated, and which is permitted by
the
   policy encoded result is placed in the certificate to participate in this algorithm.
   This may be a signature field.

Actions of the sender:

The client computes its signature over the handshake messages exchanged
so far using its ECDSA key which is specifically indicated pair with ECDSA computations performed as being useful for
   a particular algorithm or a general-purpose elliptic curve key which
   is allowed to perform a particular operation.
specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The X.509 key usage extension encodes functions a key is allowed
client conveys its signature to
   perform. the server in the CertificateVerify
message using the format defined above.

Actions of the receiver:

The relevant server extracts the client's signature from the CertificateVerify
message, and verifies the signature using the client's ECDSA public key usage bits for
that it received in the ClientCertificate message.

4.7.  Computing the Master Secret

In all the ECC-based key exchange algorithms are:

                       Algorithm   Key Usage Bit
                       _________   ________________
                       ECDSA       digitalSignature
                       ECNRA       digitalSignature
                       ECES        keyEncipherment
                       ECDH        keyAgreement
                       ECMQV       keyAgreement

                  Table 2: Pertinent X.509 specified in Section 2,
the client and server compute the master key usage bits

   A TLS entity shall not present as follows:

- They both compute a certificate which is not eligible to
   participate single shared secret K of length 20 bytes using
  their ECDH key pairs with ECDH computations performed as specified by
  the ECKAS-DH1 scheme in [IEEE1363] with the negotiated cipher suite ECSVDP-DH secret value
  derivation primitive, and shall refuse to
   communicate with a TLS peer which presents such a certificate.

10. the KDF1 key derivation primitive using
  SHA-1 [FIPS180-1].

- They both use K as the pre_master_secret, and compute the
  master_secret  from the pre_master_secret as specified in [TLS].

5.  Cipher Suites

The following table below defines the cipher suites are defined:

 CipherSuite TLS_ECES_ECDSA_NULL_SHA                   = { 0x00, 0x2C }
 CipherSuite TLS_ECES_ECDSA_WITH_RC4_128_SHA           = { 0x00, 0x2D }
 CipherSuite TLS_ECES_ECDSA_WITH_DES_CBC_SHA           = { 0x00, 0x2E }
 CipherSuite TLS_ECES_ECDSA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x2F }
 CipherSuite TLS_ECES_ECNRA_NULL_SHA                   = { 0x00, 0x30 }
 CipherSuite TLS_ECES_ECNRA_WITH_RC4_128_SHA           = { 0x00, 0x31 }
 CipherSuite TLS_ECES_ECNRA_WITH_DES_CBC_SHA           = { 0x00, 0x32 }
 CipherSuite TLS_ECES_ECNRA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x33 }
 CipherSuite TLS_ECDHE_ECDSA_NULL_SHA                  = { 0x00, 0x34 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA          = { 0x00, 0x36 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA          = { 0x00, 0x37 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x38 }
 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x39 }
 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA    = { 0x00, 0x40 }
 CipherSuite TLS_ECDHE_ECNRA_NULL_SHA                  = { 0x00, 0x41 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_RC4_128_SHA          = { 0x00, 0x42 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_DES_CBC_SHA          = { 0x00, 0x43 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x44 } specified in this document
for use with the key exchange algorithms specified in Section 2.

  CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_DES40_CBC_SHA TLS_ECDH_ECDSA_WITH_NULL_SHA                = { 0x00, 0x45 0x47 }
  CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_RC4_40_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA             = { 0x00, 0x46 0x48 }
  CipherSuite TLS_ECDH_ECDSA_NULL_SHA TLS_ECDH_ECDSA_WITH_DES_CBC_SHA             = { 0x00, 0x47 0x49 }
  CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA        = { 0x00, 0x48 0x4A }
  CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA         = { 0x00, 0x49 0x4B }
  CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA         = { 0x00, 0x4A 0x4C }
  CipherSuite TLS_ECDH_ECNRA_NULL_SHA TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA       = { 0x00, 0x4B }
  CipherSuite TLS_ECDH_ECNRA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA       = { 0x00, 0x4C }
  CipherSuite TLS_ECDH_ECNRA_WITH_DES_CBC_SHA TLS_ECDH_RSA_WITH_NULL_SHA                  = { 0x00, 0x4D }
  CipherSuite TLS_ECDH_ECNRA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA               = { 0x00, 0x4E }
  CipherSuite TLS_ECMQV_ECDSA_NULL_SHA TLS_ECDH_RSA_WITH_DES_CBC_SHA               = { 0x00, 0x4F }
  CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00, 0x50 }
  CipherSuite TLS_ECMQV_ECDSA_WITH_DES_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x51 }
  CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x52 }
  CipherSuite TLS_ECMQV_ECNRA_NULL_SHA TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA         = { 0x00, 0x53 }
  CipherSuite TLS_ECMQV_ECNRA_WITH_RC4_128_SHA TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA         = { 0x00, 0x54 }
  CipherSuite TLS_ECMQV_ECNRA_WITH_DES_CBC_SHA          = { 0x00, 0x55 }
 CipherSuite TLS_ECMQV_ECNRA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x56 }
 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA                 = { 0x00, 0x57 0x55 }
  CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA              = { 0x00, 0x58 0x56 }
  CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA              = { 0x00, 0x59 0x57 }
  CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA         = { 0x00, 0x5A 0x58 }
  CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA     = { 0x00, 0x5B 0x59 }
  CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA        = { 0x00, 0x5C 0x5A }

                       Table 3: 5: TLS ECC cipher suites

The key establishment exchange method, cipher, and hash algorithm for each of these
cipher suite suites are easily determined by examining the name. Those Ciphers
other than AES ciphers, and hash algorithms are defined in [TLS]. AES
ciphers are defined in [TLS-AES].

The cipher suites which use the "NULL" cipher or one of the "EXPORT"
key
   establishment mechanisms exchange algorithms are considered to be "exportable" cipher suites
for the purposes of the TLS protocol.

11.  Elliptic Curve Cryptography Definitions

   These definitions provide a quick reference for

Use of the elliptic curve
   terms.

   Elliptic curve         Definition to come.

   Elliptic curve point   Definition to come.

   EC parameters          Definition to come.

   EC private key         Definition to come.

   EC public key          Definition to come.

   EC key pair            Definition to come.

12.  Recommended Cipher Suites

   In order to promote common interoperability, two following cipher suites are is recommended for initial implementation:
   TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and
   TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA. Implementing these two gives
   a basis in general - server
implementations SHOULD support all of cryptographic strength, perfect forward secrecy, and
   well-accepted algorithms.

13.  References

   [ECDH] IEEE P1363 Working Draft, February, 1997.

   [ECDSA] IEEE P1363 Working Draft, February, 1997.

   [ECDSA] ANSI X9.62 Working Draft, November 17, 1997.

   [ECES] ANSI X9.63 Working Draft.

   [ECMQV] IEEE P1363 Working Draft, February, 1997.

   [ECNRA] IEEE P1363 Working Draft, February, 1997.

   [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key
   Infrastructure: Part I:  X.509 Certificate these cipher suites, and CRL Profile, <draft-
   ietf-pkix-ipki-part1-06.txt>, October 1997.

   [PKIX-ECDSA] L. Bassham, D. Johnson, W. Polk, Representation client
implementations SHOULD support at least one of
   Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and
   Signatures in Internet X.509 Public Key Infrastructure Certificates
   <draft-ietf-pkix-ipki-ecdsa-01.txt>, November 1997.

   [X9.62] ANSI X9.62 Working Draft, November 17, 1997.

14. them:

TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

Implementations MAY support any of the other cipher suites.

6.  Security Considerations

This document is entirely concerned with security mechanisms.
   Implementors

This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the
appropriate security considerations of those documents apply.

In addition implementers should take care to ensure that code which
controls security mechanisms is free of errors which might be exploited
by attackers.

15.

7. Intellectual Property Rights

The IETF has been notified of intellectual property rights claimed in
regard to the specification contained in this document. For more
information, consult the online list of claimed rights
(http://www.ietf.org/ipr.html).

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.

8. Acknowledgments

The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John
Kennedy, and Brian Minard for their help preparing this document.

9.  References

[ANSIX9.62]  ANSI X9.62-1999, "Public Key Cryptography For The Financial
             Services Industry: The Elliptic Curve Digital Signature
             Algorithm (ECDSA)", American National Standards Institute,
             1998.

[FIPS180]    FIPS 180-1, "Secure Hash Standard", National Institute of
             Standards and Technology, 1995.

[FIPS186-2]  FIPS 186-2, "Digital Signature Standard", National Institute
             of Standards and Technology, 2000.

[IEEE1363]   IEEE 1363, "Standard Specifications for Public Key
             Cryptography", Institute of Electrical and Electronics
             Engineers, 2000.

[MUST]       S. Bradner, "Key Words for Use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

[PKIX-ALG]   L. Bassham, R. Housley and W. Polk, "Algorithms and
             Identifiers for the Internet X.509 Public Key
             Infrastructure Certificate and CRL Profile", PKIX Working
             Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt,
             March 2001.

[PKIX-CERT]  W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
             Public Key Infrastructure Certificate and CRL Profile", PKIX
             Working Group Internet-Draft,
             draft-ietf-pkix-new-part1-05.txt, March 2001.

[SEC1]       SEC 1, "Elliptic Curve Cryptography", Standards for Efficient
             Cryptography Group, 2000.

[SEC2]       SEC 2, "Recommended Elliptic Curve Domain Parameters",
             Standards for Efficient Cryptography Group, 2000.

[TLS]        T. Dierks and C. Allen, "The TLS Protocol - Version 1.0,"
             IETF RFC 2246, January 1999.

[TLS-AES]    P. Chown, "AES Ciphersuites for TLS", TLS Working Group
             Internet-Draft, draft-ietf-tls-ciphersuite-03.txt,
             January 2001.

[TLS-EXT]    S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS",
             TLS Working Group Internet-Draft,
             draft-ietf-tls-wireless-00.txt, November 2000.

10.  Authors' Addresses

Authors:

Simon Blake-Wilson
Certicom Corp.
sblake-wilson@certicom.com

Tim Dierks
           Consensus Development
Certicom Corp.
timd@consensus.com

           Bill Anderson

Chris Hawk
Certicom
           banderson@certicom.com

   Contributors:

           Gilles Garon
           ggaron@aol.com Corp.
chawk@certicom.com