< draft-ietf-tls-ecc-00.txt		draft-ietf-tls-ecc-01.txt >
	Transport Layer Security Working Group T. Dierks		TLS Working Group Simon Blake-Wilson
	INTERNET-DRAFT Consensus Development Corp.		INTERNET-DRAFT Tim Dierks
	Expires September, 1998 B. Anderson		Expires: September 14, 2001 Chris Hawk
	Certicom Corp.		Certicom Corp.
	March 13, 1998		15 March 2001
	ECC Cipher Suites For TLS		ECC Cipher Suites for TLS
	draft-ietf-tls-ecc-00.txt		<draft-ietf-tls-ecc-01.txt>
	1. Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with all
	documents of the Internet Engineering Task Force (IETF), its areas,		provisions of Section 10 of RFC2026. Internet-Drafts are working
	and its working groups. Note that other groups may also distribute		documents of the Internet Engineering Task Force (IETF), its areas,
	working documents as Internet-Drafts.		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		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or made obsolete by other documents at		and may be updated, replaced, or obsoleted by other documents at any
	any time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference material
	material or to cite them other than as work in progress.		or to cite them other than as "work in progress."
	To learn the current status of any Internet-Draft, please check the		The list of current Internet-Drafts may be found at
	1id-abstracts.txt listing contained in the Internet Drafts Shadow		http://www.ietf.org/ietf/1id-abstracts.txt
	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		The list of Internet-Draft Shadow Directories may be found at
			http://www.ietf.org/shadow.html.
	This document describes additions to TLS to support the Elliptic		Abstract
	Curve Cryptosystem (ECC). The document assumes that the reader is
	familiar with the TLS protocol.
	The document defines cipher suites which use the Elliptic Curve		This document describes additions to TLS to support Elliptic Curve
	Encryption Scheme (ECES), the Elliptic Curve Digital Signature		Cryptography (ECC). In particular it defines new key exchange
	Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme		algorithms which use the Elliptic Curve Digital Signature Algorithm
	with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key		(ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme
	Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key		(ECDH), and it defines how to perform client authentication with ECDSA
	Agreement (ECMQV) key establishment algorithms. References to these		and ECDH.
	algorithms can be found in section 13.
	3. Table of Contents		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 [MUST].
	1. Status of this Memo ........................................ 1		Please send comments on this document to the TLS mailing list.
	2. Introduction ............................................... 1
	3. Table of Contents .......................................... 2
	4. Rationale .................................................. 2
	5. Elliptic Curve Key Establishment Methods ................... 3
	6. Key Establishment Operation ................................ 5
	6.1. ECES_ECDSA ................................................. 6
	6.2. ECES_ECNRA ................................................. 6
	6.3. ECDHE_ECDSA ................................................ 6
	6.4. ECDHE_ECDSA_EXPORT ......................................... 7
	6.5. ECDHE_ECNRA ................................................ 7
	6.6. ECDHE_ECNRA_EXPORT ......................................... 7
	6.7. ECDH_ECDSA ................................................. 7
	6.8. ECDH_ECNRA ................................................. 8
	6.9. ECMQV_ECDSA ................................................ 8
	6.10. ECMQV_ECNRA ................................................ 9
	6.11. ECDH_anon .................................................. 9
	6.12. ECDH_anon_EXPORT ........................................... 9
	7. Client Certification ....................................... 9
	8. Data Structures ........................................... 10
	8.1. Server Key Exchange ....................................... 10
	8.2. Certificate Request ....................................... 13
	8.3. Client Key Exchange ....................................... 14
	8.4. Certificate Verify ........................................ 15
	9. Elliptic Curve Certificates ............................... 15
	10. Cipher Suites ............................................. 16
	11. Elliptic Curve Cryptography Definitions ................... 17
	12. Recommended Cipher Suites ................................. 17
	13. References ................................................ 17
	14. Security Considerations ................................... 18
	15. Authors' Addresses ........................................ 18
	4. Rationale		Table of Contents
	Several design goals drove our choice of key establishment		1. Introduction ................................................. 2
	algorithms:		2. Elliptic Curve Key Exchange Algorithms ....................... 4
			2.1. ECDH_ECDSA ................................................... 5
			2.2. ECDH_ECDSA_EXPORT ............................................ 5
			2.3. ECDH_RSA ..................................................... 6
			2.4. ECDH_RSA_EXPORT .............................................. 6
			2.5. ECDH_anon .................................................... 6
			2.6. ECDH_anon_EXPORT ............................................. 6
			3. ECC Client Authentication .................................... 7
			3.1. ECDSA_sign ................................................... 7
			3.2. ECDSA_fixed_ECDH ............................................. 8
			3.3. RSA_fixed_ECDH ............................................... 9
			4. Data Structures and Computations ............................. 9
			4.1. Server Certificate .......................................... 10
			4.2. Server Key Exchange ......................................... 11
			4.3. Certificate Request ......................................... 15
			4.4. Client Certificate .......................................... 15
			4.5. Client Key Exchange ......................................... 16
			4.6. Certificate Verify .......................................... 18
			4.7. Computing the Master Secret ................................. 19
			5. Cipher Suites ............................................... 19
			6. Security Considerations ..................................... 20
			7. Intellectual Property Rights ................................ 20
			8. Acknowledgments ............................................. 21
			9. References .................................................. 21
			10. Authors' Addresses .......................................... 22
	1. A desire to replicate all of the functionality and operating		1. Introduction
	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		This document describes additions to TLS to support Elliptic Curve
	cryptography, we did not want to define any cipher suites which		Cryptography (ECC). In particular, it defines:
	would require certificates with export-strength keys; thus,
	exportable cipher suites are only defined for those key
	establishment mechanisms which use the certificate key for
	authentication rather than for key establishment.
	These criteria for key establishment algorithms, when combined with a		- new key exchange algorithms which use the Elliptic Curve Digital
	number of symmetric algorithms, led to a large number of possible		Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman
	cipher suites. This is problematic in that it could lead to a lack of		Key Agreement Scheme (ECDH); and
	interoperability due to implementors supporting different subsets of
	the available cipher suites. In order to alleviate this, we have
	indicated two of the total cipher suites as recommended (see section
	12). Unless there are specific reasons to choose other cipher
	suites, implementors should implement the recommended suites first.
	5. Elliptic Curve Key Establishment Methods		- new client authentication methods which use ECDSA and ECDH.
	Key establishment is the terminology used in ISO standards to refer		In order to enable the use of these features within TLS, the document
	to the methods of establishing a shared key between two or more		defines enhanced data structures to convey the information that the
	parties. Within key establishment there are two classifications:		mechanisms need to exchange, the computational procedures involved in
	The operation is called key transport when only one party contributes		the operation of the mechanisms, and new cipher suites based on the
	to the generation of the shared key. The operation is called key		mechanisms.
	agreement when 2 or more parties contribute to the generation of the
	shared key. For the purposes of this definition, the key in question
	is the premaster secret: TLS uses the master secret generation
	process to ensure that both parties contribute to the eventual master
	secret.
	The cipher suites defined here use the following key establishment		Use of ECC within TLS may provide both bandwidth and computational
	methods:		savings compared to other public-key cryptographic techniques.
			Furthermore, the 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
			sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based
			on the running times of the best algorithms known today.
	ECES_ECDSA Elliptic-curve encryption is used for the key		Symmetric | ECC | DH/DSA/RSA
	transport; the server's certificate is signed		80 | 163 | 1024
	using ECDSA.		128 | 283 | 3072
			192 | 409 | 7680
			256 | 571 | 15360
	ECES_ECNRA Elliptic-curve encryption is used for the key		Table 1: Comparable key sizes (in bits)
	transport; the server's certificate is signed
	using ECNRA.
	ECDHE_ECDSA Ephemeral elliptic-curve Diffie-Hellman is used		The savings that ECC may offer are likely to become increasingly
	for the key agreement; the server signs the		desirable with the widespread use of TLS by wireless devices -
	parameters with an ECDSA key and is		discussed, for example, in [TLS-EXT].
	authenticated with a certificate signed with
	ECDSA.
	ECDHE_ECDSA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in		This document assumes the reader is familiar with both ECC and TLS. ECC
	export strength is used for the key agreement;		is described in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE
	the server signs the parameters with an ECDSA		1363 [IEEE1363], and SEC 1 [SEC1]. TLS is described in RFC 2246 [TLS].
	key and is authenticated with a certificate
	signed with ECDSA.
	ECDHE_ECNRA Ephemeral elliptic-curve Diffie-Hellman is used		The choice of mechanisms included in this document was motivated by a
	for the key agreement; the server signs the		desire to provide mechanisms which are secure, which are as efficient
	parameters with an ECNRA key and is		as possible, and which are capable of replicating all of the
	authenticated with a certificate signed with		functionality and operating modes found in the existing TLS mechanisms
	ECNRA.		based on integer factorization and discrete logarithm cryptographic
			systems. TLS includes a substantial variety of functionality and
			operating modes in consideration of the variety of applications with
			which TLS is used.
	ECDHE_ECNRA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in		The desire described above led to the inclusion of a substantial number
	export strength is used for the key agreement;		of ECC-based mechanisms. In order to encourage interoperability, a
	the server signs the parameters with an ECNRA		small subset of the mechanisms are identified as "recommended" - these
	key and is authenticated with a certificate		mechanisms are capable of meeting the requirements of many
	signed with ECNRA.		applications and they should therefore be used unless an application
			profile of this document states otherwise, or unless in a particular
			environment considerations such as export regulations mandate
			otherwise.
	ECDH_ECDSA Fixed elliptic-curve Diffie-Hellman is used for		The remainder of this document is organized as follows. Section 2
	the key agreement; the server's certificate is		specifies key exchange algorithms for TLS using ECC. Section 3
	signed with ECDSA.		specifies how client authentication is performed using ECC. Section 4
			describes the TLS-specific data structures and computations involved in
			the operation of the ECC mechanisms. Section 5 defines cipher suites
			based on the ECC key exchange algorithms. Sections 6-8 discuss security
			considerations, intellectual property rights, and acknowledgements
			respectively. Section 9 supplies references cited elsewhere in the
			document, and Section 10 gives the authors' contact details.
	ECDH_ECNRA Fixed elliptic-curve Diffie-Hellman is used for		2. Elliptic Curve Key Exchange Algorithms
	the key agreement; the server's certificate is
	signed with ECNRA.
	ECMQV_ECDSA Ephemeral elliptic-curve MQV is used for key		This document defines six new key exchange algorithms based on ECC for
	agreement and authentication; the server is		use within TLS.
	authenticated with a certificate signed with
	ECDSA.
	ECMQV_ECNRA Ephemeral elliptic-curve MQV is used for key		The table below summarizes the new key exchange algorithms.
	agreement and authentication; the server is
	authenticated with a certificate signed with
	ECNRA.
	ECDH_anon Anonymous elliptic-curve Diffie-Hellman is used		Key
	for the key agreement.		Exchange
			Algorithm Description Key size limit
	ECDH_anon_EXPORT Anonymous elliptic-curve Diffie-Hellman in		ECDH_ECDSA ECDH with ECDSA signatures None
	export strength is used for the key agreement.		ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits,
			ECDSA=none
			ECDH_RSA ECDH with RSA signatures None
			ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits,
			RSA = none
			ECDH_anon Anonymous ECDH, no signatures None
			ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits
	Key establishment mechanisms which indicate that they are for export		Table 2: Key exchange algorithms
	strength should use an ECC key for the key agreement of no more than
	113 bits. A 113-bit ECC key provides security that is roughly
	equivalent to a 512-bit RSA key and is expected to be eligible for
	export. The following table relates ECC key sizes to RSA key sizes
	of equivalent security. These key sizes are considered equivalent in
	terms of work factor required to recover the private key using
	currently known fastest methods for solving the underlying
	mathematical problems of ECC and RSA.
	ECC RSA Time to break (MIPS-years)		Note that the key exchange algorithms marked "anon" do not provide
	________ _________ __________________________		authentication of the server or the client, and, like other "anon" TLS
	106 bits 512 bits 1E4 MY		key exchange algorithms, may be subject to man-in-the-middle attacks.
	132 bits 768 bits 1E8 MY		Implementations of these algorithms SHOULD provide authentication by
	160 bits 1024 bits 1E11 MY		other means.
	191 bits 1536 bits 1E14 MY
	211 bits 2048 bits 1E20 MY
	Table 1: ECC and RSA key sizes for equivalent security		The remainder of this section describes these key exchange algorithms
			in detail. For each key exchange algorithm, this involves specification
			of the contents of the handshake messages related to key exchange -
			server certificate, server key exchange, client certificate, and client
			key exchange - as well as specification of the computations involved in
			the calculation of the master secret.
	6. Key Establishment Operation		2.1. ECDH_ECDSA
	The TLS key establishment protocol involves this message exchange:		ECDH is used to compute the master secret. The server is authenticated
			via a certificate containing an ECDH public key signed with ECDSA.
	Client Server		Specifically this key exchange algorithm MUST proceed as follows:
	__________________ ___________________
	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		- The server provides a static ECDH public key in the server
	* - Message is not sent under some conditions		certificate message using the format described in Section 4.1. The
			certificate is signed using ECDSA.
	Of these messages, the ones involved in the key establishment itself		- The server key exchange message is not sent.
	are the server's Certificate message, the ServerKeyExchange, the
	client's Certificate message, and the ClientKeyExchange.
	In order to specify the ECC cipher suites, we must specify the		- Unless client authentication using ECDH is performed as specified in
	following elements for each key establishment algorithm:		Sections 3.2 and 3.3, the client provides an ephemeral ECDH public
			key in the client key exchange message using the format described in
			Section 4.5. In this case, the client certificate and certificate
			verify message are not sent unless client authentication is performed
			using ECDSA as specified in Section 3.1, or another signature
			algorithm.
	- The format of the server's certificate.		- If client authentication using ECDH is performed, the client provides
			a static ECDH public key in the client certificate message using the
			format described in Section 4.4. In this case an empty client key
			exchange message is sent using the format described in Section 4.5, and
			the certificate verify message is not sent.
	- The format of the server key exchange message		- The client and server compute the master secret using their ECDH key
			pairs as specified in Section 4.7.
	- For methods in which the client's certificate can participate in		ECDH computations for this key exchange algorithm are performed
	the key agreement, the format of the client's certificate and the		according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
	criteria for deciding if this certificate is eligible to		ECSVDP-DH secret value derivation primitive, and the KDF1 key
	participate in the key agreement.		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].
	- The format of the client key exchange message		2.2. ECDH_ECDSA_EXPORT
	- How to arrive at the premaster secret given all the preceding		Export-strength ECDH is used to compute the master secret. The server
	information.		is authenticated via a certificate containing an ECDH public key signed
			with ECDSA.
	Several different key establishment modes are available. In order to		This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA,
	allow full negotiation of supported algorithms, the signature		except that the key size for ECDH public keys is constrained to 163
	algorithm used for the server's X.509 certificate is encoded into the		bits or less. Here the key size of an elliptic curve public key refers
	cipher suite for those key establishment mechanisms where no		to the size of the underlying finite field over which the elliptic
	signature algorithm is used; for those key establishments which		curve is defined.
	utilize signature algorithms, the certificate signature algorithm is
	expected to be the same as the algorithm used in the key
	establishment.
	6.1. ECES_ECDSA		2.3. ECDH_RSA
	In ECES_ECDSA, the server sends a certificate with an ECES-capable		ECDH is used to compute the master secret. The server is authenticated
	public key in it. The server's certificate should be signed with		via a certificate containing an ECDH public key signed with RSA.
	ECDSA. A ServerKeyExchange message is not sent because the server's
	certificate contains all the necessary keying information for the
	client to complete the key establishment.
	The client's certificate is not involved in the key establishment for		This key exchange MUST proceed in the same way as ECDH_ECDSA, except
	this method, although the client can still be authenticated via the		that the server's certificate is signed with RSA.
	normal mechanism.
	The client generates a 48 byte premaster secret, encrypts it using		2.4. ECDH_RSA_EXPORT
	ECES using the public key from the server's certificate, and sends it
	to the server in the ClientKeyExchange message (see section 8.3).
	This premaster secret is decrypted by the server and both sides use		Export-strength ECDH is used to compute the master secret. The server
	it to generate the master secret for this TLS session.		is authenticated via a certificate containing an ECDH public key signed
			with RSA.
	6.2. ECES_ECNRA		This key exchange algorithm MUST proceed in the same way as ECDH_RSA,
			except that the key size for ECDH public keys is constrained to be 163
			bits or less.
	ECES_ECNRA is the same as ECES_ECDSA except for the fact that the		2.5. ECDH_anon
	server's certificate is signed by its CA with ECNRA.
	6.3. ECDHE_ECDSA		Anonymous ECDH is used to compute the master secret.
	In ECDHE_ECDSA, the server's certificate has an ECDSA key and is, in		Specifically this key exchange algorithm MUST proceed as follows:
	turn, signed by its CA with ECDSA. The ServerKeyExchange message
	contains an ephemeral ECDH key and a specification of the curve for
	this key. (see section 8.1). These parameters are signed with the
	server's authenticated ECDSA key.
	The client's certificate is not involved in the key establishment for		- The server certificate message is not sent.
	this method, although the client can still be authenticated via the
	normal mechanism.
	The client should verify the signature on the ServerKeyExchange		- The server provides an ephemeral ECDH public key in the server key
	message and generate an ECDH key on the same curve as the server's		exchange message using the format described in Section 4.2.
	ephemeral key. The client encodes the public half of that key into
	the ClientKeyExchange message and sends it to the server.
	The client and server perform an ECDH key agreement using their		- The client certificate message is not sent.
	private keys and the public keys they have sent to each other. The
	resultant shared secret is the premaster secret.
	6.4. ECDHE_ECDSA_EXPORT		- The client provides an ephemeral ECDH public key in the client key
			exchange message using the format described in Section 4.5.
	ECDHE_ECDSA_EXPORT is the same as ECDHE_ECDSA except for the fact		- The client and server compute the master secret using their ECDH
	that the curve used for the server's ephemeral ECDH key should be no		key pairs as specified in Section 4.7.
	longer than 113 bits. Because the server's certified key is only
	used for authentication, its length is unrestricted.
	6.5. ECDHE_ECNRA		ECDH computations for this key exchange algorithm are performed
			according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
			ECSVDP-DH secret value derivation primitive, and the KDF1 key
			derivation primitive using SHA-1 [FIPS180-1].
	ECDHE_ECNRA is the same as ECDHE_ECDSA except for the fact that the		2.6. ECDH_anon_EXPORT
	server's public key is an ECNRA key and the server's certificate is
	signed by its CA with ECNRA.
	6.6. ECDHE_ECNRA_EXPORT		Export-strength, anonymous ECDH is used to compute the master secret.
			This key exchange algorithm MUST proceed in the same way as ECDH_anon,
			except that the key size for ECDH public keys is constrained to 163
			bits or less.
	ECDHE_ECNRA_EXPORT is the same as ECDHE_ECNRA except for the fact		3. ECC Client Authentication
	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 for authentication, its length is unrestricted.
	6.7. ECDH_ECDSA		This document defines three new ECC-based client authentication methods
			- ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH.
	In ECDH_ECDSA, the server's certificate contains an ECDH public key.		To encourage interoperability, implementations SHOULD support
	This certificate is signed by the server's CA using ECDSA. The		ECDSA_fixed_ECDH. Implementations MAY support any of the other client
	ServerKeyExchange message is not sent because the server's		authentication methods.
	certificate contains all the necessary keying information for the
	client to complete the key establishment.
	If the server requests client authentication and includes the		The remainder of this section specifies these ECC-based client
	ecdsa_fixed_dh or ecnra_fixed_dh client certificate types (see		authentication methods. The following information is provided for each
	section 8.2) and the client has a certificate which contains an ECDH		method: which key exchange algorithms the method may be used with, what
	key on the same curve as the server's public key, and this		constraints apply to the method, and the formats of the certificate
	certificate is otherwise eligible to be used for client		request, client certificate, client key exchange, and certificate
	authentication, then the client's certified public key is used in		verify messages.
	conjunction with the server's public key to do an ECDH key agreement;
	the resultant shared secret is the premaster key. In this situation,
	the client key exchange message is empty when sent and the client
	CertificateVerify message is not sent, as both the client and the
	server are authenticated by their ability to arrive at the same
	premaster secret.
	If client certification is not requested or if the client does not		3.1. ECDSA_sign
	have a certificate with a suitable ECDH public key, the client can
	generate an ephemeral key on the same curve as the server's public
	key. This key is encoded into the ClientKeyExchange message (see
	section 8.3) and used in conjunction with the server's key to
	complete the ECDH key agreement, yielding the premaster secret.
	6.8. ECDH_ECNRA		The client supplies a certificate containing an ECDSA public key, and
			authenticates itself by signing the certificate verify message with its
			ECDSA key pair.
	ECDH_ECNRA is the same as ECDH_ECDSA except for the fact that the		This client authentication method MUST proceed as follows.
	server's certificate is signed by its CA with ECNRA.
	6.9. ECMQV_ECDSA		Applicable key exchange algorithms:
	In ECMQV_ECDSA, the server's certificate contains an ECMQV key and is		- This client authentication method is eligible for use with all the
	signed by the server's CA with ECDSA. The server then generates an		non-anonymous ECC-based key exchange algorithms specified in Section
	temporary key pair and sends the public half of the temporary key in		2, and all the existing non-anonymous TLS key exchange algorithms
	the ServerKeyExchange message (see section 8.1).		specified in [TLS].
	If the server requests client authentication and includes the		Restrictions:
	ecdsa_mqv or ecnra_mqv client certificate types (see section 8.2) and
	the client has a certificate which contains an ECMQV key on the same
	curve as the server's public key, and this certificate is otherwise
	eligible to be used for client authentication, then the client should
	send that certificate, then generate a temporary key and send the
	public half of that key in 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 the premaster secret. The client CertificateVerify
	message is not sent, as both the client and the server are
	authenticated by their ability to arrive at the same premaster
	secret.
	If client certification is not requested or if the client does not		- In order to perform this method, the client must possess a certified
	have a certificate with a suitable ECMQV public key, the client		ECDSA public key.
	should generate two temporary key pairs on the same curve as the
	server's public key. The 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 the other takes the place of the
	certified key. Each side performs an MQV key agreement using the
	peer's public keys and its own private keys, yielding the premaster
	secret.
	6.10. ECMQV_ECNRA		Message exchange:
	ECMQV_ECNRA is the same as ECMQV_ECDSA except for the fact that the		- The server requests use of the ECDSA_sign method by sending a
	server's certificate is signed by its CA with ECNRA.		certificate request message containing the value "ecdsa_sign" using
			the format described in Section 4.3. When the client receives this
			request, it checks that it possesses an appropriate certificate and
			that it is willing to proceed.
	6.11. ECDH_anon		- If the client proceeds, it sends its certificate containing its ECDSA
			public key in the client certificate message using the format
			described in Section 4.4. It signs the handshake messages exchanged
			so far with its ECDSA key pair and conveys the resulting signature to
			the server in the certificate verify message using the format
			specified in Section 4.6.
	In ECDH_anon, an anonymous Elliptic-Curve Diffie-Hellman operation is		- (If the client does not proceed, it may perform client authentication
	used to arrive at the premaster secret. In this case, the server is		using another method suggested by the server in the certificate
	not authenticated and may not request that the client authenticate		request message in which case the client certificate and the
	itself. The server's Certificate message is not sent. The		certificate verify message are sent in accordance with the selected
	ServerKeyExchange message contains the specification of a curve and a		method, or it may proceed with the key exchange without client
	Diffie-Hellman public key (see section 8.1). The client responds		authentication - in which case the client certificate and certificate
	with a ClientKeyExchange message containing a Diffie-Hellman public		verify messages are not sent.)
	key on the same curve; the premaster secret is the shared secret
	resulting from an Elliptic Curve Diffie-Hellman key agreement with
	these keys.
	6.12. ECDH_anon_EXPORT		ECDSA computations for this client authentication method are performed
			according to ANSI X9.62 [ANSIX962] using the hash function SHA-1
			[FIPS180-1].
	ECDH_anon_EXPORT is the same as ECDH_anon except for the fact that		3.2. ECDSA_fixed_ECDH
	the curve used for the server's ephemeral ECDH key should be no
	longer than 113 bits.
	7. Client Certification		The client supplies an ECDSA-signed certificate containing an ECDH
			public key 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 only be performed by a
			party possessing the private key corresponding to one of the ECDH
			public keys exchanged.)
	Six new client certificate types have been added: ecdsa_sign,		This client authentication method MUST proceed as follows.
	ecnra_sign, ecdsa_fixed_dh, ecnra_fixed_dh, ecdsa_mqv, and ecnra_mqv.
	As noted above, the fixed_dh and mqv types are used in key
	establishment methods which allow the client's certified key to
	participate in key agreement. In these cases, the CertificateVerify
	message is not sent; the client's ability to arrive at the same
	premaster secret as 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		Applicable key exchange algorithms:
	operation if it has a key which can be used with that algorithm.
	Because elliptic curve keys have the same mathematical properties 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 to the
	key's eligibility, it must be defined using the same curve parameters
	as the server's key to be used in a operation with it. Of course,
	the use of a certificate is always subject to any and all policy
	constraints placed on it.
	In these certificates, the ecdsa or ecnra refers to the algorithm		- This method is eligible for use with all the non-anonymous ECC-based
	which the CA uses to sign the client's certificate.		key exchange algorithms specified in Section 2.
	The ecdsa_sign and ecnra_sign certificate types are used in other key		Restrictions:
	establishment methods and in cases where the client can not or
	chooses not to supply a suitable certificate to participate in one of
	the above methods. In these cases, the client must send a
	CertificateVerify message to demonstrate its control of the private
	half key of the certified key pair. (See section 8.4).
	Certificates requested with the ecdsa_sign ClientCertificateType must		- In order to perform this client authentication method, the client
	include an ECDSA public key and be signed by the CA with ECDSA;		must possess an ECDSA-signed certificate containing an ECDH public
	ecnra_sign certificates must include an ECNRA key and be signed with		key using the same elliptic curve domain parameters as the ECDH
	ECNRA.		public key supplied by the server in the server certificate message.
	With all key establishment methods, it is permissible to request a		Message exchange:
	client certificate using a different algorithm than the one used for
	the server's certificate; for example, a server doing a ECDHE_ECDSA
	or ECMQV_ECDSA key establishment could still request an ECNRA client
	certificate.
	8. Data Structures		- The server requests use of the ECDSA_fixed_ECDH method by sending a
			certificate request message containing the value "ecdsa_fixed_ecdh"
			using the format described in Section 4.3. When the client receives
			this request, it checks that it possesses an appropriate certificate
			and that it is willing to proceed.
	Here the descriptions of the data structures exchanged are given.		- If the client proceeds, it sends its certificate containing its ECDH
	The presentation language is the same as that used in the TLS		public key in the client certificate message using the format
	specification. Because these specifications extend the TLS protocol		described in Section 4.4. It sends an empty client key exchange
	specification, these descriptions should be merged with those in TLS		message using the format described in Section 4.5. It does not send
	and in any other specifications which extend TLS. This means that		the certificate verify message. It uses its static ECDH key pair,
	enum types may not specify all the possible values and structures		along with the server's ECDH public key) when computing the master
	with multiple formats chosen with a select() clause may not indicate		secret and finished message.
	all the possible cases.
	8.1. Server Key Exchange		- (If the client does not proceed, it may perform client authentication
			using another method suggested by the server in the certificate
			request message, or it may proceed with the key exchange without
			client authentication - in which case the client certificate and
			certificate verify messages are not sent.)
	This messages is sent in the following key establishment methods:		ECDH computations for this key exchange algorithm are performed
			according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
			ECSVDP-DH secret value derivation primitive, and the KDF1 key
			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].
	ECDHE_ECDSA		3.3. RSA_fixed_ECDH
	ECDHE_ECDSA_EXPORT
	ECDHE_ECNRA
	ECDHE_ECNRA_EXPORT
	ECMQV_ECDSA
	ECMQV_ECNRA
	ECDH_anon
	ECDH_anon_EXPORT
	It can contain elliptic curve Diffie-Hellman keys, either signed or		The client supplies an RSA-signed certificate containing an ECDH
	unsigned, or MQV parameters.		public key 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 only be performed by a
			party possessing the private key corresponding to one of the ECDH
			public keys exchanged.)
	Structure of this message:		This client authentication method MUST proceed in the same manner as
			the ECDSA_fixed_ECDH method, except that the client's certificate must
			be signed with RSA, and the server requests use of the method by
			sending a certificate request message containing the value
			"rsa_fixed_ecdh".
	enum { ec_eces,		4. Data Structures and Computations
	ec_diffie_hellman,
	ec_menezes_qu_vanstone } KeyExchangeAlgorithm;
	enum { ec_prime_p (1),		This section specifies the data structures and computations used by the
	ec_characteristic_two (2), (255) } ECFieldID;		ECC-based mechanisms specified in Sections 2 and 3. The presentation
			language used here is the same as that used in 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.
	enum { ec_basis_onb, ec_basis_trinomial,		4.1. Server Certificate
	ec_basis_pentanomial } ECBasisType;
	struct {		This message is sent in the following key exchange algorithms:
	opaque a <1..2^8-1>;
	opaque b <1..2^8-1>;
	opaque seed <0..2^8-1>;
	} ECCurve;
	a, b: These parameters specify the coefficients of the elliptic		All the non-anonymous ECC-based key exchange algorithms specified in
	curve. Each value shall be the octet string representation of a		Section 2.
	field element following the conversion routine in [X9.62], section
	4.3.1.
	seed: This is an optional parameter used to derive the coefficients		Meaning of this message:
	of a randomly generated elliptic curve.
	struct {		This message is used to authentically convey the server's static public
	opaque point <1..2^8-1>;		key to the client. The appropriate certificate types are given in the
	} ECPoint;		following table.
	point: This is the octet string representation of an elliptic curve		Key Exchange Algorithm Certificate Type
	point following the conversion routine in [X9.62], section 4.4.2.a.
	The representation format is defined following the definition in
	[X9.62], section 4.4.
	struct {		ECDH_ECDSA ECC public key; the certificate must
	ECFieldID field;		allow the key to be used for key
	select (field) {		agreement. The certificate must be
	case ec_prime_p:		signed with ECDSA.
	opaque prime_p <1..2^8-1>;
	case ec_characteristic_two:
	uint16 m;		ECDH_ECDSA_EXPORT ECC public key which can be used for key
	ECBasisType basis;		agreement; key size must be 163 bits or
	select (basis) {		less. Certificate must be signed with
	case ec_basis_onb:		ECDSA.
	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>;
	} ECParameters;
	field: This identifies the finite field over which the elliptic curve		ECDH_RSA ECC public key which can be used for key
	is defined.		agreement. Certificate must be signed
			with RSA.
	prime_p: This is the odd prime defining the field Fp.		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.
	m: This is the degree of the characteristic-two field F2^m.		Table 3: Server certificate types
	k: The exponent k for the trinomical basis representation x^m + x^k +		[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
	1.		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.
	k1, k2, k3: The exponents for the pentanomial representation x^m +		Structure of this message:
	x^k3 + x^k2 + x^k1 + 1.
	curve: Specifies the coefficients a and b of the elliptic curve E.		Identical to the TLS Certificate format.
	base: The base point P on the elliptic curve.		Actions of the sender:
	order: The order n of the base point. The order of a point P is the		The server constructs an appropriate certificate chain and conveys it
	smallest possible integer n such that nP = 0 (the point at infinity).		to the client in the Certificate message.
	cofactor: The integer h = #E(Fq)/n, where #E(Fq) represents the		Actions of the receiver:
	number of points on the elliptic curve E defined over the field Fq.
	struct {		The client validates the certificate chain, extracts the server's
	ECParameters curve_params;		public key, and checks that the key is of the correct type for the key
	ECPoint public;		exchange algorithm.
	} ServerECDHParams;
	curve_params: This specifies the curve on which the elliptic-curve		4.2. Server Key Exchange
	Diffie-Hellman key agreement is to occur.
	public: The ephemeral public key for the elliptic-curve Diffie-		This message is sent in the following key exchange algorithms:
	Hellman key agreement.
	struct {		Both the anonymous ECC-based key exchange algorithms specified in
	ECPoint temp_public;		Section 2.
	} ServerMQVParams;
	temp_public: The temporary MQV public key; the curve on which the MQV		Meaning of this message:
	operation will take place is specified by the server's certificate.
	enum { ec_dsa, ec_nra } SignatureAlgorithm;		This message is used to convey the server's ephemeral ECDH public key
			(and the corresponding elliptic curve domain parameters) to the client.
	select (SignatureAlgorithm) {		Structure of this message:
	case ec_dsa:
	digitally-signed struct {
	opaque sha_hash[20];
	};
	case ec_nra:
	digitally-signed struct {
	opaque sha_hash[20];
	};
	} Signature;
	select (KeyExchangeAlgorithm) {		The TLS ServerKeyExchange message is extended as follows.
	case ec_diffie_hellman:
	ServerECDHParams params;
	Signature signed_params;
	case ec_menezes_qu_vanstone:
	ServerMQVParams params;
	} ServerKeyExchange;
	Note: The anonymous case for Signature is used for ECDH_anon and		enum { ec_diffie_hellman } KeyExchangeAlgorithm;
	ECDH_anon_EXPORT key establishment methods: in this case, the
	Signature element is empty.
	8.2. Certificate Request		ec_diffie_hellman
			Indicates the ServerKeyExchange message is to contain an ECDH public
			key.
	The only addition to this message is six new types for the client		enum { explicit_prime (1), explicit_char2 (2),
	certificate.		named_curve (3), (255) } ECCurveType;
	Structure of this message:		explicit_prime
			Indicates the elliptic curve domain parameters will be conveyed
			verbosely, and that the underlying finite field is a prime field.
	enum {		explicit_char2
	ecdsa_sign(5), ecnra_sign(6),		Indicates the elliptic curve domain parameters will be conveyed
	ecdsa_fixed_dh(7), ecnra_fixed_dh(8),		verbosely, and that the underlying finite field is a characteristic 2
	ecdsa_mqv (9), ecnra_mqv (10), (255)		field.
	} ClientCertificateType;
	8.3. Client Key Exchange		named_curve
			Indicates that a named curve will be used. The use of this option is
			strongly recommended.
	This message is sent in all key exchanges. It can contain either an		struct {
	ECES encrypted secret, an ECDH public key (for use in ECDHE or		opaque a <1..2^8-1>;
	ECDH_anon key establishment methods), an ECMQV temporary public key,		opaque b <1..2^8-1>;
	or two temporary keys for use with MQV when the client does not have		opaque seed <0..2^8-1>;
	a suitable certificate.		} ECCurve;
	Structure of this message:		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 [X9.62], section 4.3.3.
	struct {		seed
	select (PublicValueEncoding) {		This is an optional parameter used to derive the coefficients of a
	case implicit: struct { };		randomly generated elliptic curve.
	case explicit: ECPoint ecdh_Yc;
	} ecdh_public;
	} ClientECDiffieHellmanPublic;
	If the client has sent a certificate with an ECDH key, the		struct {
	PublicValueEncoding will be implicit and this message will be empty.		opaque point <1..2^8-1>;
	Otherwise, ecdh_Yc will be the client's public value for the Diffie-		} ECPoint;
	Hellman key agreement.
	struct {		point
	select (PublicValueEncoding) {		This is the byte string representation of an elliptic curve point
	case implicit: struct { };		following the conversion routine in [X9.62], section 4.3.6.
	case explicit: ECPoint ecmqv;
	} ecmqv_public;
	ECPoint ecmqv_temp;
	} ClientECMQVPublic;
	If the client has sent a certificate with an MQV key, the		enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
	PublicValueEncoding will be implicit and the ecmqv_public field will
	be empty; otherwise, ecmqv will contain 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		ec_basis_trinomial
	saved by generating only one ephemeral key and sending two copies:		Indicates representation of a characteristic two field using a
	one in ecmqv and one in ecmqv_temp.		trinomial basis.
	struct {		ec_basis_pentanomial
	select (KeyExchangeAlgorithm) {		Indicates representation of a characteristic two field using a
	case ec_eces: EncryptedPreMasterSecret;		pentanomial basis.
	case ec_diffie_hellman: ClientECDiffieHellmanPublic;
	case ec_menezes_qu_vanstone: ClientECMQVPublic;
	} exchange_keys;
	} ClientKeyExchange;
	In the ECES case, the premaster secret will be sent encrypted with		enum {
	the server's public key. The standard TLS definition of		sect163k1 (1), sect163r1 (2), sect163r2 (3),
	EncryptedPreMasterSecret is suitable for this transmission.		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;
	8.4. Certificate Verify		sect163k1, etc
			Indicates use of the corresponding recommended curve specified in SEC 2
			[SEC2]. Note that many of these curves are also recommended in ANSI
			X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2].
	This message is sent when the client has sent a certificate which did		struct {
	not participate in a Diffie-Hellman or Menezes-Qu-Vanstone key		ECCurveType curve_type;
	agreement.		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;
	This type needs no new definition: the CertificateVerify message in		curve_type
	TLS uses the Signature type, which we have extended for ECDSA and		This identifies the type of the elliptic curve domain parameters.
	ECNRA (see section 8.1).
	9. Elliptic Curve Certificates		prime_p
			This is the odd prime defining the field Fp.
	All X.509 certificates must be in compliance with the PKIX profile of		curve
	the X.509 standard [PKIX]. Elliptic curve keys should be encoded		Specifies the coefficients a and b of the elliptic curve E.
	into X.509 certificates as 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,		base
	ECES, ECDH, or ECMQV key, it means a public key which is capable of		Specifies the base point G on the elliptic curve.
	performing a particular algorithm and which is permitted by the
	policy encoded in the certificate to participate in this algorithm.
	This may be a key which is specifically indicated as being useful for
	a particular algorithm or a general-purpose elliptic curve key which
	is allowed to perform a particular operation.
	The X.509 key usage extension encodes functions a key is allowed to		order
	perform. The relevant key usage bits for algorithms are:		Specifies the order n of the base point.
	Algorithm Key Usage Bit		cofactor
	_________ ________________		Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number
	ECDSA digitalSignature		of points on the elliptic curve E defined over the field Fq.
	ECNRA digitalSignature
	ECES keyEncipherment
	ECDH keyAgreement
	ECMQV keyAgreement
	Table 2: Pertinent X.509 key usage bits		m
			This is the degree of the characteristic-two field F2^m.
	A TLS entity shall not present a certificate which is not eligible to		k
	participate in the negotiated cipher suite and shall refuse to		The exponent k for the trinomial basis representation x^m+x^k+1.
	communicate with a TLS peer which presents such a certificate.
	10. Cipher Suites		k1, k2, k3
			The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1.
	The following cipher suites are defined:		namedcurve
			Specifies a recommended set of elliptic curve domain parameters.
	CipherSuite TLS_ECES_ECDSA_NULL_SHA = { 0x00, 0x2C }		struct {
	CipherSuite TLS_ECES_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x2D }		ECParameters curve_params;
	CipherSuite TLS_ECES_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x2E }		ECPoint public;
	CipherSuite TLS_ECES_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x2F }		} ServerECDHParams;
	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 }
	CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x45 }
	CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x46 }
	CipherSuite TLS_ECDH_ECDSA_NULL_SHA = { 0x00, 0x47 }
	CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }
	CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }
	CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }
	CipherSuite TLS_ECDH_ECNRA_NULL_SHA = { 0x00, 0x4B }
	CipherSuite TLS_ECDH_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x4C }
	CipherSuite TLS_ECDH_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x4D }
	CipherSuite TLS_ECDH_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4E }
	CipherSuite TLS_ECMQV_ECDSA_NULL_SHA = { 0x00, 0x4F }
	CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x50 }
	CipherSuite TLS_ECMQV_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x51 }
	CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x52 }
	CipherSuite TLS_ECMQV_ECNRA_NULL_SHA = { 0x00, 0x53 }
	CipherSuite TLS_ECMQV_ECNRA_WITH_RC4_128_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 }
	CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x58 }
	CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x59 }
	CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x5A }
	CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x5B }
	CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5C }
	Table 3: TLS ECC cipher suites		curve_params
			Specifies the elliptic curve domain parameters associated with the
			ECDH public key.
	The key establishment method, cipher, and hash algorithm for each		public
	cipher suite are easily determined by examining the name. Those		The ephemeral ECDH public key.
	cipher suites which use the "NULL" cipher or one of the "EXPORT" key
	establishment mechanisms are considered to be "exportable" cipher
	suites for the purposes of the TLS protocol.
	11. Elliptic Curve Cryptography Definitions		select (KeyExchangeAlgorithm) {
			case ec_diffie_hellman:
			ServerECDHParams params;
			Signature signed_params;
			} ServerKeyExchange;
	These definitions provide a quick reference for the elliptic curve		params
	terms.		Specifies the ECDH public key and associated domain parameters.
	Elliptic curve Definition to come.		signed_params
			This element is empty for all the key exchange algorithms specified in
			this document.
	Elliptic curve point Definition to come.		Actions of the sender:
	EC parameters Definition to come.		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 [IEEE1363]. It conveys this information
			to the client in the ServerKeyExchange message using the format defined
			above.
	EC private key Definition to come.		Actions of the recipient:
	EC public key Definition to come.		The client retrieves the server's elliptic curve domain parameters and
			ephemeral ECDH public key from the ServerKeyExchange message.
	EC key pair Definition to come.		4.3. Certificate Request
	12. Recommended Cipher Suites		This message is sent when requesting the following client
			authentication methods:
	In order to promote common interoperability, two cipher suites are		Any of the ECC-based client authentication methods specified in
	recommended for initial implementation:		Section 3.
	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and
	TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA. Implementing these two gives
	a basis of cryptographic strength, perfect forward secrecy, and
	well-accepted algorithms.
	13. References		Meaning of this message:
	[ECDH] IEEE P1363 Working Draft, February, 1997.		The server uses this message to indicate which client authentication
			methods the server would like to use.
	[ECDSA] IEEE P1363 Working Draft, February, 1997.		Structure of this message:
	[ECDSA] ANSI X9.62 Working Draft, November 17, 1997.		The TLS CertificateRequest message is extended as follows.
	[ECES] ANSI X9.63 Working Draft.		enum {
			ecdsa_sign (5), rsa_fixed_ecdh (6),
			ecdsa_fixed_ecdh(7), (255)
			} ClientCertificateType;
	[ECMQV] IEEE P1363 Working Draft, February, 1997.		ecdsa_sign, etc
			Indicates that the server would like to use the corresponding client
			authentication method specified in Section 3.
	[ECNRA] IEEE P1363 Working Draft, February, 1997.		Actions of the sender:
	[PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key		The server decides which client authentication methods it would like to
	Infrastructure: Part I: X.509 Certificate and CRL Profile, <draft-		use, and conveys this information to the client using the format
	ietf-pkix-ipki-part1-06.txt>, October 1997.		defined above.
	[PKIX-ECDSA] L. Bassham, D. Johnson, W. Polk, Representation of		Actions of the receiver:
	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.		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.
	14. Security Considerations		4.4. Client Certificate
	This document is entirely concerned with security mechanisms.		This message is sent in the following client authentication methods:
	Implementors should take care to ensure that code which controls
	security mechanisms is free of errors which might be exploited by
	attackers.
	15. Authors' Addresses		All the ECC-based client authentication methods specified in Section 3.
	Authors:		Meaning of this message:
	Tim Dierks		This message is used to authentically convey the client's static public
	Consensus Development		key to the server. The appropriate certificate types are given in the
	timd@consensus.com		following table.
	Bill Anderson		Client Authentication Certificate Type
	Certicom		Method
	banderson@certicom.com
	Contributors:		ECDSA_sign ECC public key which can be used for
			signing.
	Gilles Garon		ECDSA_fixed_ECDH ECC public key which can be used for key
	ggaron@aol.com		agreement. Certificate must be signed
			with ECDSA.
			RSA_fixed_ECDH ECC public 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 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, and the "digitalSignature" bit MUST be set for
			ECDSA certificates.
			Structure of this message:
			Identical to the TLS 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 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 fixed ECDH is not being used, the message
			contains the client's ephemeral ECDH public key, otherwise the message
			is empty.
			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 { yes, no } EphemeralPublicKey;
			yes, no
			Indicates whether or not the client is providing an ephemeral ECDH
			public key.
			struct {
			select (EphemeralPublicKey) {
			case yes: ECPoint ecdh_Yc;
			case no: struct { };
			} ecdh_public;
			} ClientECDiffieHellmanPublic;
			ecdh_Yc
			Contains the client's ephemeral ECDH public key.
			struct {
			select (KeyExchangeAlgorithm) {
			case ec_diffie_hellman: ClientECDiffieHellmanPublic;
			} exchange_keys;
			} ClientKeyExchange;
			Actions of the sender:
			The client selects an ephemeral ECDH public key corresponding to the
			parameters it received from the server according to the ECKAS-DH1
			scheme from IEEE 1363 [IEEE1363]. 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
			ServerKeyExchange message and checks that the public key represents a
			point of the elliptic curve.
			4.6. Certificate Verify
			This message is sent in the following client authentication methods:
			ECDSA_sign
			Meaning of the message:
			This message contains an ECDSA signature on the handshake messages in
			order to authenticate the client to the server.
			Structure of this message:
			The TLS CertificateVerify message is extended 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 signature on the handshake messages exchanged so far.
			According to [ANSIX962], the 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 [ANSIX962], 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 the handshake messages exchanged
			so far using its ECDSA key pair with ECDSA computations performed as
			specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The
			client conveys its signature to the server in the CertificateVerify
			message using 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 client's ECDSA public key
			that it received in the ClientCertificate message.
			4.7. Computing the Master Secret
			In all the ECC-based key exchange algorithms specified in Section 2,
			the client and server compute the master key as follows:
			- They both compute a 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 ECSVDP-DH secret value
			derivation primitive, and 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 table below defines the cipher suites specified in this document
			for use with the key exchange algorithms specified in Section 2.
			CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }
			CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }
			CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }
			CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }
			CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B }
			CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C }
			CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x4B }
			CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x4C }
			CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x4D }
			CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x4E }
			CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA = { 0x00, 0x4F }
			CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x50 }
			CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x51 }
			CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x52 }
			CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x53 }
			CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x54 }
			CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x55 }
			CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x56 }
			CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x57 }
			CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x58 }
			CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x59 }
			CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5A }
			Table 5: TLS ECC cipher suites
			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 [TLS]. AES
			ciphers are defined in [TLS-AES].
			The cipher suites which use the "NULL" cipher or one of the "EXPORT"
			key exchange algorithms are considered to be "exportable" cipher suites
			for the purposes of the TLS protocol.
			Use of the following cipher suites is recommended in general - server
			implementations SHOULD support all of these cipher suites, and client
			implementations SHOULD support at least one of 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.
			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.
			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
			Certicom Corp.
			timd@consensus.com
			Chris Hawk
			Certicom Corp.
			chawk@certicom.com
End of changes. 180 change blocks.
	653 lines changed or deleted		540 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/