< draft-ietf-tls-ecc-08.txt		draft-ietf-tls-ecc-09.txt >
	TLS Working Group V. Gupta		TLS Working Group V. Gupta
	Internet-Draft Sun Labs		Internet-Draft Sun Labs
	Expires: September 2, 2005 S. Blake-Wilson		Expires: October 9, 2005 S. Blake-Wilson
	BCI		BCI
	B. Moeller		B. Moeller
	University of Calgary		University of Calgary
	C. Hawk		C. Hawk
	Corriente Networks		Corriente Networks
	N. Bolyard		N. Bolyard
	Mar. 2005		April 7, 2005
	ECC Cipher Suites for TLS		ECC Cipher Suites for TLS
	<draft-ietf-tls-ecc-08.txt>		<draft-ietf-tls-ecc-09.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		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 obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 2, 2005.		This Internet-Draft will expire on October 9, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes new key exchange algorithms based on Elliptic		This document describes new key exchange algorithms based on Elliptic
	Curve Cryptography (ECC) for the TLS (Transport Layer Security)		Curve Cryptography (ECC) for the TLS (Transport Layer Security)
	protocol. In particular, it specifies the use of Elliptic Curve		protocol. In particular, it specifies the use of Elliptic Curve
	Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of		Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	Please send comments on this document to the TLS mailing list.		Please send comments on this document to the TLS mailing list.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5		2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5
	2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7		2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8		2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8		2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Client Authentication . . . . . . . . . . . . . . . . . . . 9		3. Client Authentication . . . . . . . . . . . . . . . . . . . 9
	3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10		3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10
	3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10		3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10
	4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11		4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11
	5. Data Structures and Computations . . . . . . . . . . . . . . 12		5. Data Structures and Computations . . . . . . . . . . . . . . 12
	5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12		5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12
	5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . 15		5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15
	5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16		5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16
	5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17		5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18
	5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20		5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22
	5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21		5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23
	5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22		5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24
	5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23		5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25
	5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25		5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26
	5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25		5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26
	6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26		6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Security Considerations . . . . . . . . . . . . . . . . . . 28		7. Security Considerations . . . . . . . . . . . . . . . . . . 30
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 30		9.1 Normative References . . . . . . . . . . . . . . . . . . . 32
	9.2 Informative References . . . . . . . . . . . . . . . . . . 30		9.2 Informative References . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . 33		Intellectual Property and Copyright Statements . . . . . . . 35
	1. Introduction		1. Introduction
	Elliptic Curve Cryptography (ECC) is emerging as an attractive		Elliptic Curve Cryptography (ECC) is emerging as an attractive
	public-key cryptosystem for mobile/wireless environments. Compared		public-key cryptosystem for mobile/wireless environments. Compared
	to currently prevalent cryptosystems such as RSA, ECC offers		to currently prevalent cryptosystems such as RSA, ECC offers
	equivalent security with smaller key sizes. This is illustrated in		equivalent security with smaller key sizes. This is illustrated in
	the following table, based on [12], which gives approximate		the following table, based on [13], which gives approximate
	comparable key sizes for symmetric- and asymmetric-key cryptosystems		comparable key sizes for symmetric- and asymmetric-key cryptosystems
	based on the best-known algorithms for attacking them.		based on the best-known algorithms for attacking them.
	Symmetric | ECC | DH/DSA/RSA		Symmetric | ECC | DH/DSA/RSA
	-------------+---------+------------		-------------+---------+------------
	80 | 163 | 1024		80 | 163 | 1024
	112 | 233 | 2048		112 | 233 | 2048
	128 | 283 | 3072		128 | 283 | 3072
	192 | 409 | 7680		192 | 409 | 7680
	256 | 571 | 15360		256 | 571 | 15360
	Table 1: Comparable key sizes (in bits)		Table 1: Comparable key sizes (in bits)
	Figure 1
	Smaller key sizes result in power, bandwidth and computational		Smaller key sizes result in power, bandwidth and computational
	savings that make ECC especially attractive for constrained		savings that make ECC especially attractive for constrained
	environments.		environments.
	This document describes additions to TLS to support ECC. In		This document describes additions to TLS to support ECC. In
	particular, it defines		particular, it defines
	o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement		o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
	scheme with long-term or ephemeral keys to establish the TLS		scheme with long-term or ephemeral keys to establish the TLS
	premaster secret, and		premaster secret, and
	o the use of fixed-ECDH certificates and ECDSA for authentication of		o the use of fixed-ECDH certificates and ECDSA for authentication of
	TLS peers.		TLS peers.
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	provides an overview of ECC-based key exchange algorithms for TLS.		provides an overview of ECC-based key exchange algorithms for TLS.
	Section 3 describes the use of ECC certificates for client		Section 3 describes the use of ECC certificates for client
	authentication. TLS extensions that allow a client to negotiate the		authentication. TLS extensions that allow a client to negotiate the
	use of specific curves and point formats are presented in Section 4.		use of specific curves and point formats are presented in Section 4.
	Section 5 specifies various data structures needed for an ECC-based		Section 5 specifies various data structures needed for an ECC-based
	handshake, their encoding in TLS messages and the processing of those		handshake, their encoding in TLS messages and the processing of those
	messages. Section 6 defines new ECC-based cipher suites and		messages. Section 6 defines new ECC-based cipher suites and
	identifies a small subset of these as recommended for all		identifies a small subset of these as recommended for all
	implementations of this specification. Section 7 and Section 8		implementations of this specification. Section 7 and Section 8
	mention security considerations and acknowledgments, respectively.		mention security considerations and acknowledgments, respectively.
	This is followed by a list of references cited in this document, the		This is followed by a list of references cited in this document, the
	authors' contact information, and statements on intellectual property		authors' contact information, and statements on intellectual property
	rights and copyrights.		rights and copyrights.
	Implementation of this specification requires familiarity with TLS		Implementation of this specification requires familiarity with TLS
	[2], TLS extensions [3] and ECC [4][5][6][8] .		[2], TLS extensions [3] and ECC [4][5][6][8].
	2. Key Exchange Algorithms		2. Key Exchange Algorithms
	This document introduces five new ECC-based key exchange algorithms		This document introduces five new ECC-based key exchange algorithms
	for TLS. All of them use ECDH to compute the TLS premaster secret		for TLS. All of them use ECDH to compute the TLS premaster secret
	and differ only in the lifetime of ECDH keys (long-term or ephemeral)		and differ only in the lifetime of ECDH keys (long-term or ephemeral)
	and the mechanism (if any) used to authenticate them. The derivation		and the mechanism (if any) used to authenticate them. The derivation
	of the TLS master secret from the premaster secret and the subsequent		of the TLS master secret from the premaster secret and the subsequent
	generation of bulk encryption/MAC keys and initialization vectors is		generation of bulk encryption/MAC keys and initialization vectors is
	independent of the key exchange algorithm and not impacted by the		independent of the key exchange algorithm and not impacted by the
	introduction of ECC.		introduction of ECC.
	The table below summarizes the new key exchange algorithms which		The table below summarizes the new key exchange algorithms which
	mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]),		mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]),
	respectively.		respectively.
	Key		Key
	Exchange		Exchange
	Algorithm Description		Algorithm Description
	--------- -----------		--------- -----------
	ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.		ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
	ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.		ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
	ECDH_RSA Fixed ECDH with RSA-signed certificates.		ECDH_RSA Fixed ECDH with RSA-signed certificates.
	ECDHE_RSA Ephemeral ECDH with RSA signatures.		ECDHE_RSA Ephemeral ECDH with RSA signatures.
	ECDH_anon Anonymous ECDH, no signatures.		ECDH_anon Anonymous ECDH, no signatures.
	Table 2: ECC key exchange algorithms		Table 2: ECC key exchange algorithms
	Figure 2
	The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward		The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
	secrecy. With ECDHE_RSA, a server can reuse its existing RSA		secrecy. With ECDHE_RSA, a server can reuse its existing RSA
	certificate and easily comply with a constrained client's elliptic		certificate and easily comply with a constrained client's elliptic
	curve preferences (see Section 4). However, the computational cost		curve preferences (see Section 4). However, the computational cost
	incurred by a server is higher for ECDHE_RSA than for the traditional		incurred by a server is higher for ECDHE_RSA than for the traditional
	RSA key exchange which does not provide forward secrecy.		RSA key exchange which does not provide forward secrecy.
	The ECDH_RSA mechanism requires a server to acquire an ECC		The ECDH_RSA mechanism requires a server to acquire an ECC
	certificate but the certificate issuer can still use an existing RSA		certificate but the certificate issuer can still use an existing RSA
	key for signing. This eliminates the need to update the trusted key		key for signing. This eliminates the need to update the trusted key
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 11 ¶
	for constrained devices unable to support RSA.		for constrained devices unable to support RSA.
	The anonymous key exchange algorithm does not provide authentication		The anonymous key exchange algorithm does not provide authentication
	of the server or the client. Like other anonymous TLS key exchanges,		of the server or the client. Like other anonymous TLS key exchanges,
	it is subject to man-in-the-middle attacks. Implementations of this		it is subject to man-in-the-middle attacks. Implementations of this
	algorithm SHOULD provide authentication by other means.		algorithm SHOULD provide authentication by other means.
	Note that there is no structural difference between ECDH and ECDSA		Note that there is no structural difference between ECDH and ECDSA
	keys. A certificate issuer may use X509.v3 keyUsage and		keys. A certificate issuer may use X509.v3 keyUsage and
	extendedKeyUsage extensions to restrict the use of an ECC public key		extendedKeyUsage extensions to restrict the use of an ECC public key
	to certain computations. This document refers to an ECC key as		to certain computations. This document refers to an ECC key as ECDH-
	ECDH-capable if its use in ECDH is permitted. ECDSA-capable is		capable if its use in ECDH is permitted. ECDSA-capable is defined
	defined similarly.		similarly.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	Certificate*		Certificate*
	ServerKeyExchange*		ServerKeyExchange*
	CertificateRequest*+		CertificateRequest*+
	<-------- ServerHelloDone		<-------- ServerHelloDone
	Certificate*+		Certificate*+
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*+		CertificateVerify*+
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Figure 1: Message flow in a full TLS handshake
	* message is not sent under some conditions		* message is not sent under some conditions
	+ message is not sent unless the client is		+ message is not sent unless client authentication
	authenticated		is desired
	Figure 3		Figure 1: Message flow in a full TLS handshake
	Figure 1 shows all messages involved in the TLS key establishment		Figure 1 shows all messages involved in the TLS key establishment
	protocol (aka full handshake). The addition of ECC has direct impact		protocol (aka full handshake). The addition of ECC has direct impact
	only on the ClientHello, the ServerHello, the server's Certificate		only on the ClientHello, the ServerHello, the server's Certificate
	message, the ServerKeyExchange, the ClientKeyExchange, the		message, the ServerKeyExchange, the ClientKeyExchange, the
	CertificateRequest, the client's Certificate message, and the		CertificateRequest, the client's Certificate message, and the
	CertificateVerify. Next, we describe each ECC key exchange algorithm		CertificateVerify. Next, we describe each ECC key exchange algorithm
	in greater detail in terms of the content and processing of these		in greater detail in terms of the content and processing of these
	messages. For ease of exposition, we defer discussion of client		messages. For ease of exposition, we defer discussion of client
	authentication and associated messages (identified with a + in Figure		authentication and associated messages (identified with a + in
	1) until Section 3 and of the optional ECC-specific extensions (which		Figure 1) until Section 3 and of the optional ECC-specific extensions
	impact the Hello messages) until Section 4.		(which impact the Hello messages) until Section 4.
	2.1 ECDH_ECDSA		2.1 ECDH_ECDSA
	In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable		In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
	public key and be signed with ECDSA.		public key and be signed with ECDSA.
	A ServerKeyExchange MUST NOT be sent (the server's certificate		A ServerKeyExchange MUST NOT be sent (the server's certificate
	contains all the necessary keying information required by the client		contains all the necessary keying information required by the client
	to arrive at the premaster secret).		to arrive at the premaster secret).
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 28 ¶
	ClientKeyExchange message (except when using client authentication		ClientKeyExchange message (except when using client authentication
	algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the		algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
	modifications from section Section 3.2 or Section 3.3 apply).		modifications from section Section 3.2 or Section 3.3 apply).
	Both client and server MUST perform an ECDH operation and use the		Both client and server MUST perform an ECDH operation and use the
	resultant shared secret as the premaster secret. All ECDH		resultant shared secret as the premaster secret. All ECDH
	calculations are performed as specified in Section 5.10		calculations are performed as specified in Section 5.10
	2.2 ECDHE_ECDSA		2.2 ECDHE_ECDSA
	In ECDHE_ECDSA, the server's certificate MUST contain an		In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
	ECDSA-capable public key and be signed with ECDSA.		capable public key and be signed with ECDSA.
	The server MUST send its ephemeral ECDH public key and a		The server MUST send its ephemeral ECDH public key and a
	specification of the corresponding curve in the ServerKeyExchange		specification of the corresponding curve in the ServerKeyExchange
	message. These parameters MUST be signed with ECDSA using the		message. These parameters MUST be signed with ECDSA using the
	private key corresponding to the public key in the server's		private key corresponding to the public key in the server's
	Certificate.		Certificate.
	The client MUST generate an ECDH key pair on the same curve as the		The client MUST generate an ECDH key pair on the same curve as the
	server's ephemeral ECDH key and send its public key in the		server's ephemeral ECDH key and send its public key in the
	ClientKeyExchange message.		ClientKeyExchange message.
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	possession of the private key corresponding to the certified public		possession of the private key corresponding to the certified public
	key and the CertificateVerify message is unnecessary.		key and the CertificateVerify message is unnecessary.
	3.3 RSA_fixed_ECDH		3.3 RSA_fixed_ECDH
	This authentication mechanism is identical to ECDSA_fixed_ECDH except		This authentication mechanism is identical to ECDSA_fixed_ECDH except
	the client's certificate MUST be signed with RSA.		the client's certificate MUST be signed with RSA.
	4. TLS Extensions for ECC		4. TLS Extensions for ECC
	Two new TLS extensions --- (i) the Supported Elliptic Curves		Two new TLS extensions are defined in this specification: (i) the
	Extension, and (ii) the Supported Point Formats Extension --- allow a		Supported Elliptic Curves Extension, and (ii) the Supported Point
	client to negotiate the use of specific curves and point formats		Formats Extension. These allow negotiating the use of specific
	(e.g. compressed v/s uncompressed), respectively. These extensions		curves and point formats (e.g. compressed vs. uncompressed),
	are especially relevant for constrained clients that may only support		respectively, during a handshake starting a new session. These
	a limited number of curves or point formats. They follow the general		extensions are especially relevant for constrained clients that may
	approach outlined in [3]. The client enumerates the curves and point		only support a limited number of curves or point formats. They
	formats it supports by including the appropriate extensions in its		follow the general approach outlined in [3]; message details are
	ClientHello message. By echoing that extension in its ServerHello,		specified in Section 5. The client enumerates the curves it supports
	the server agrees to restrict its key selection or encoding to the		and the point formats it can parse by including the appropriate
	choices specified by the client.		extensions in its ClientHello message. The server similarly
			enumerates the point formats it can parse by including an extension
			in its ServerHello message.
	A TLS client that proposes ECC cipher suites in its ClientHello		A TLS client that proposes ECC cipher suites in its ClientHello
	message SHOULD include these extensions. Servers implementing ECC		message SHOULD include these extensions. Servers implementing ECC
	cipher suites MUST support these extensions and negotiate the use of		cipher suites MUST support these extensions, and when a client uses
	an ECC cipher suite only if they can complete the handshake while		these extensions, servers MUST NOT negotiate the use of an ECC cipher
	limiting themselves to the curves and compression techniques		suite unless they can complete the handshake while respecting the
	enumerated by the client. This eliminates the possibility that a		choice of curves and compression techniques specified by the client.
	negotiated ECC handshake will be subsequently aborted due to a		This eliminates the possibility that a negotiated ECC handshake will
	client's inability to deal with the server's EC key.		be subsequently aborted due to a client's inability to deal with the
			server's EC key.
	These extensions MUST NOT be included if the client does not propose		These extensions MUST NOT be included if the client does not propose
	any ECC cipher suites. A client that proposes ECC cipher suites may		any ECC cipher suites. A client that proposes ECC cipher suites may
	choose not to include these extension. In this case, the server is		choose not to include these extension. In this case, the server is
	free to choose any one of the elliptic curves or point formats listed		free to choose any one of the elliptic curves or point formats listed
	in Section 5. That section also describes the structure and		in Section 5. That section also describes the structure and
	processing of these extensions in greater detail.		processing of these extensions in greater detail.
			In the case of session resumption, the server simply ignores the
			Supported Elliptic Curves Extension and the Supported Point Formats
			Extension as appearing in the current ClientHello message. These
			extensions only play a role during handshakes negotiating a new
			session.
	5. Data Structures and Computations		5. Data Structures and Computations
	This section specifies the data structures and computations used by		This section specifies the data structures and computations used by
	ECC-based key mechanisms specified in Section 2, Section 3 and		ECC-based key mechanisms specified in Section 2, Section 3 and
	Section 4. The presentation language used here is the same as that		Section 4. The presentation language used here is the same as that
	used in TLS [2]. Since this specification extends TLS, these		used in TLS [2]. Since this specification extends TLS, these
	descriptions should be merged with those in the TLS specification and		descriptions should be merged with those in the TLS specification and
	any others that extend TLS. This means that enum types may not		any others that extend TLS. This means that enum types may not
	specify all possible values and structures with multiple formats		specify all possible values and structures with multiple formats
	chosen with a select() clause may not indicate all possible cases.		chosen with a select() clause may not indicate all possible cases.
	5.1 Client Hello Extensions		5.1 Client Hello Extensions
	When this message is sent:		This section specifies two TLS extensions that can be included with
			the ClientHello message as described in [3], the Supported Elliptic
			Curves Extension and the Supported Point Formats Extension.
	The ECC extensions SHOULD be sent along with any ClientHello message		When these extensions are sent:
	that proposes ECC cipher suites.
	Meaning of this message:		The extensions SHOULD be sent along with any ClientHello message that
			proposes ECC cipher suites.
	These extensions allow a constrained client to enumerate the elliptic		Meaning of these extensions:
	curves and/or point formats it supports.
	Structure of this message:		These extensions allow a client to enumerate the elliptic curves it
			supports and/or the point formats it can parse.
			Structure of these extensions:
	The general structure of TLS extensions is described in [3] and this		The general structure of TLS extensions is described in [3] and this
	specification adds two new types to ExtensionType.		specification adds two new types to ExtensionType.
	enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;		enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
	elliptic_curves: Indicates the set of elliptic curves supported by		[[ EDITOR: The values used for elliptic_curves and ec_point_formats
	the client. For this extension, the opaque extension_data field		have been left as ??. These values will be assigned when this draft
	contains EllipticCurveList.		progresses to RFC. (The examples below will have to be changed
	ec_point_formats: Indicates the set of point formats supported by		accordingly.) ]]
	the client. For this extension, the opaque extension_data field
	contains ECPointFormatList.		elliptic_curves (Supported Elliptic Curves Extension): Indicates the
			set of elliptic curves supported by the client. For this
			extension, the opaque extension_data field contains
			EllipticCurveList.
			ec_point_formats (Supported Point Formats Extension): Indicates the
			set of point formats that the client can parse. For this
			extension, the opaque extension_data field contains
			ECPointFormatList.
	enum {		enum {
	sect163k1 (1), sect163r1 (2), sect163r2 (3),		sect163k1 (1), sect163r1 (2), sect163r2 (3),
	sect193r1 (4), sect193r2 (5), sect233k1 (6),		sect193r1 (4), sect193r2 (5), sect233k1 (6),
	sect233r1 (7), sect239k1 (8), sect283k1 (9),		sect233r1 (7), sect239k1 (8), sect283k1 (9),
	sect283r1 (10), sect409k1 (11), sect409r1 (12),		sect283r1 (10), sect409k1 (11), sect409r1 (12),
	sect571k1 (13), sect571r1 (14), secp160k1 (15),		sect571k1 (13), sect571r1 (14), secp160k1 (15),
	secp160r1 (16), secp160r2 (17), secp192k1 (18),		secp160r1 (16), secp160r2 (17), secp192k1 (18),
	secp192r1 (19), secp224k1 (20), secp224r1 (21),		secp192r1 (19), secp224k1 (20), secp224r1 (21),
	secp256k1 (22), secp256r1 (23), secp384r1 (24),		secp256k1 (22), secp256r1 (23), secp384r1 (24),
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 40 ¶
	characteristic-2 curves, respectively (the curve parameters must		characteristic-2 curves, respectively (the curve parameters must
	be encoded explicitly in ECParameters).		be encoded explicitly in ECParameters).
	struct {		struct {
	NamedCurve elliptic_curve_list<1..2^8-1>		NamedCurve elliptic_curve_list<1..2^8-1>
	} EllipticCurveList;		} EllipticCurveList;
	Items in elliptic_curve_list are ordered according to the client's		Items in elliptic_curve_list are ordered according to the client's
	preferences (favorite choice first).		preferences (favorite choice first).
	As an example, a client that only supports secp192r1 (aka NIST P-192)		As an example, a client that only supports secp192r1 (aka NIST P-192;
	and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would		value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and
	include an elliptic_curves extension with the following octets:		prefers to use secp192r1 would include a TLS extension consisting of
			the following octets:
	00 ?? 00 03 02 13 15		00 ?? 00 03 02 13 15
	A client that supports arbitrary explicit binary polynomial curves		A client that supports arbitrary explicit characteristic-2 curves
	would include an extension with the following octets:		(value 254 = 0xFE) would include an extension consisting of the
			following octets:
	00 ?? 00 02 01 fe		00 ?? 00 02 01 FE
	enum { uncompressed (0), ansiX963_compressed (1),
	ansiX963_hybrid (2), (255)		enum { uncompressed (0), ansiX962_compressed (1),
			ansiX962_hybrid (2), reserved (3 .. 255)
	} ECPointFormat;		} ECPointFormat;
	struct {		struct {
	ECPointFormat ec_point_format_list<1..2^8-1>		ECPointFormat ec_point_format_list<1..2^8-1>
	} ECPointFormatList;		} ECPointFormatList;
	Three point formats are included in the defintion of ECPointFormat		Three point formats are included in the definition of ECPointFormat
	above. The uncompressed point format is the default format that		above. The uncompressed point format is the default format in that
	implementations of this document MUST support. The		implementations of this document MUST support it. The
	ansix963_compressed format reduces bandwidth by including only the		ansiX962_compressed format reduces bandwidth by including only the
	x-coordinate and a single bit of the y-coordinate of the point. The		x-coordinate and a single bit of the y-coordinate of the point. The
	ansix963_hybrid format includes both the full y-coordinate and the		ansiX962_hybrid format includes both the full y-coordinate and the
	compressed y-coordinate to allow flexibility and improve efficiency		compressed y-coordinate to allow flexibility and improve efficiency
	in some cases. Implementations of this document MAY support the		in some cases. Implementations of this document MAY support the
	ansix963_compressed and ansix963_hybrid point formats.		ansiX962_compressed and ansiX962_hybrid point formats. (These three
			formats are described in [6].) Values 248 through 255 are reserved
			for private use.
	Items in ec_point_format_list are ordered according to the client's		Items in ec_point_format_list are ordered according to the client's
	preferences (favorite choice first).		preferences (favorite choice first).
	A client that only supports the uncompressed point format includes an		A client that can parse only the uncompressed point format includes
	extension with the following octets:		an extension consisting of the following octets:
	00 ?? 00 02 01 00		00 ?? 00 02 01 00
	A client that prefers the use of the ansiX963_compressed format over		A client that prefers the use of the ansiX962_compressed format over
	uncompressed may indicate that preference by including an extension		uncompressed may indicate that preference by including an extension
	with the following octets:		consisting of the following octets:
	00 ?? 00 03 02 01 00		00 ?? 00 03 02 01 00
	Actions of the sender:		Actions of the sender:
	A client that proposes ECC cipher suites in its ClientHello appends		A client that proposes ECC cipher suites in its ClientHello message
	these extensions (along with any others) enumerating the curves and		appends these extensions (along with any others), enumerating the
	point formats it supports.		curves it supports and the point formats it can parse. Clients
			SHOULD send both the Supported Elliptic Curves Extension and the
			Supported Point Formats Extension. If the Supported Point Formats
			Extension is indeed sent, it MUST contain the value 0 (uncompressed)
			as one of the items in the list of point formats.
	Actions of the receiver:		Actions of the receiver:
	A server that receives a ClientHello containing one or both of these		A server that receives a ClientHello containing one or both of these
	extensions MUST use the client's enumerated capabilities to guide its		extensions MUST use the client's enumerated capabilities to guide its
	selection of an appropriate cipher suite. One of the proposed ECC		selection of an appropriate cipher suite. One of the proposed ECC
	cipher suites must be negotiated only if the server can successfully		cipher suites must be negotiated only if the server can successfully
	complete the handshake while using the curves and point formats		complete the handshake while using the curves and point formats
	supported by the client.		supported by the client (cf. Section 5.3 and Section 5.4).
	NOTE: A server participating in an ECDHE-ECDSA key exchange may use		NOTE: A server participating in an ECDHE-ECDSA key exchange may use
	different curves for (i) the ECDSA key in its certificate, and (ii)		different curves for (i) the ECDSA key in its certificate, and (ii)
	the ephemeral ECDH key in the ServerKeyExchange message. The server		the ephemeral ECDH key in the ServerKeyExchange message. The server
	must consider the "elliptic_curves" extension in selecting both of		must consider the "elliptic_curves" extension in selecting both of
	these curves.		these curves.
	If a server does not understand the "elliptic_curves" extension or is		If a server does not understand the "elliptic_curves" extension or is
	unable to complete the ECC handshake while restricting itself to the		unable to complete the ECC handshake while restricting itself to the
	enumerated curves, it MUST NOT negotiate the use of an ECC cipher		enumerated curves, it MUST NOT negotiate the use of an ECC cipher
	suite. Depending on what other cipher suites are proposed by the		suite. Depending on what other cipher suites are proposed by the
	client and supported by the server, this may result in a fatal		client and supported by the server, this may result in a fatal
	handshake failure alert due to the lack of common cipher suites.		handshake failure alert due to the lack of common cipher suites.
	5.2 Server Hello Extensions		5.2 Server Hello Extension
	When this message is sent:
	The ServerHello ECC extensions are sent in response to a Client Hello		This section specifies a TLS extension that can be included with the
	message containing ECC extensions when negotiating an ECC cipher		ServerHello message as described in [3], the Supported Point Formats
	suite.		Extension.
	Meaning of this message:		When this extension is sent:
	These extensions indicate the server's agreement to use only the		The Supported Point Formats Extension is included in a ServerHello
	elliptic curves and point formats supported by the client during the		message in response to a ClientHello message containing the Supported
	ECC-based key exchange.		Point Formats Extension when negotiating an ECC cipher suite.
	Structure of this message:		Meaning of this extensions:
	The ECC extensions echoed by the server are the same as those in the		This extension allows a server to enumerate the point formats it can
	ClientHello except the "extension_data" field is empty.		parse (for the curve that will appear in its ServerKeyExchange
			message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
			exchange algorithm, or for the curve that is used in the server's
			public key that will appear in its Certificate message when using the
			ECDH_ECDSA or ECDH_RSA key exchange algorithm).
	For example, a server indicates its acceptance of the client's		Structure of this extension:
	elliptic_curves extension by sending an extension with the following
	octets:
	00 ?? 00 00		The server's Supported Point Formats Extension has the same structure
			as the client's Supported Point Formats Extension. Items in
			elliptic_curve_list here are ordered according to the server's
			preference (favorite choice first). Note that the server may include
			items that were not found in the client's list (e.g., the server may
			prefer to receive points in compressed format even when a client
			cannot parse this format: the same client may nevertheless be capable
			to output points in compressed format).
	Actions of the sender:		Actions of the sender:
	A server makes sure that it can complete a proposed ECC key exchange		A server that selects an ECC cipher suite in response to a
	mechanism by restricting itself to the curves/point formats supported		ClientHello message including a Supported Point Formats Extension
	by the client before sending these extensions.		appends this extension (along with others) to its ServerHello
			message, enumerating the point formats it can parse. The Supported
			Point Formats Extension, when used, MUST contain the value 0
			(uncompressed) as one of the items in the list of point formats.
	Actions of the receiver:		Actions of the receiver:
	A client that receives a ServerHello with ECC extensions proceeds		A client that receives a ServerHello message containing a Supported
	with an ECC key exchange assured that it will be able to handle the		Point Formats Extension MUST respect the server's choice of point
	server's EC key(s).		formats during the handshake (cf. Section 5.6 and Section 5.7). If
			no Supported Point Formats Extension is received with the
			ServerHello, this is equivalent to an extension allowing only the
			uncompressed point format.
	5.3 Server Certificate		5.3 Server Certificate
	When this message is sent:		When this message is sent:
	This message is sent in all non-anonymous ECC-based key exchange		This message is sent in all non-anonymous ECC-based key exchange
	algorithms.		algorithms.
	Meaning of this message:		Meaning of this message:
	skipping to change at page 17, line 6 ¶		skipping to change at page 17, line 34 ¶
	Table 3: Server certificate types		Table 3: Server certificate types
	Structure of this message:		Structure of this message:
	Identical to the TLS Certificate format.		Identical to the TLS Certificate format.
	Actions of the sender:		Actions of the sender:
	The server constructs an appropriate certificate chain and conveys it		The server constructs an appropriate certificate chain and conveys it
	to the client in the Certificate message.		to the client in the Certificate message. If the client has used a
			Supported Elliptic Curves Extension, the public key in the server's
			certificate MUST respect the client's choice of elliptic curves; in
			particular, the public key MUST employ a named curve (not the same
			curve as an explicit curve) unless the client has indicated support
			for explicit curves of the appropriate type. If the client has used
			a Supported Point Formats Extension, both the server's public key
			point and (in the case of an explicit curve) the curve's base point
			MUST respect the client's choice of point formats. (A server that
			cannot satisfy these requirements must not choose an ECC cipher suite
			in its ServerHello message.)
	Actions of the receiver:		Actions of the receiver:
	The client validates the certificate chain, extracts the server's		The client validates the certificate chain, extracts the server's
	public key, and checks that the key type is appropriate for the		public key, and checks that the key type is appropriate for the
	negotiated key exchange algorithm.		negotiated key exchange algorithm.
	5.4 Server Key Exchange		5.4 Server Key Exchange
	When this message is sent:		When this message is sent:
	skipping to change at page 17, line 30 ¶		skipping to change at page 18, line 21 ¶
	Meaning of this message:		Meaning of this message:
	This message is used to convey the server's ephemeral ECDH public key		This message is used to convey the server's ephemeral ECDH public key
	(and the corresponding elliptic curve domain parameters) to the		(and the corresponding elliptic curve domain parameters) to the
	client.		client.
	Structure of this message:		Structure of this message:
	enum { explicit_prime (1), explicit_char2 (2),		enum { explicit_prime (1), explicit_char2 (2),
	named_curve (3), (255) } ECCurveType;		named_curve (3), reserved(4 .. 255) } ECCurveType;
	explicit_prime: Indicates the elliptic curve domain parameters are		explicit_prime: Indicates the elliptic curve domain parameters are
	conveyed verbosely, and the underlying finite field is a prime		conveyed verbosely, and the underlying finite field is a prime
	field.		field.
	explicit_char2: Indicates the elliptic curve domain parameters are		explicit_char2: Indicates the elliptic curve domain parameters are
	conveyed verbosely, and the underlying finite field is a		conveyed verbosely, and the underlying finite field is a
	characteristic-2 field.		characteristic-2 field.
	named_curve: Indicates that a named curve is used. This option		named_curve: Indicates that a named curve is used. This option
	SHOULD be used when applicable.		SHOULD be used when applicable.
			Values 248 through 255 are reserved for private use.
	struct {		struct {
	opaque a <1..2^8-1>;		opaque a <1..2^8-1>;
	opaque b <1..2^8-1>;		opaque b <1..2^8-1>;
	} ECCurve;		} ECCurve;
	a, b: These parameters specify the coefficients of the elliptic		a, b: These parameters specify the coefficients of the elliptic
	curve. Each value contains the byte string representation of a		curve. Each value contains the byte string representation of a
	field element following the conversion routine in Section 4.3.3 of		field element following the conversion routine in Section 4.3.3 of
	ANSI X9.62 [6].		ANSI X9.62 [6].
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 48 ¶
	opaque b <1..2^8-1>;		opaque b <1..2^8-1>;
	} ECCurve;		} ECCurve;
	a, b: These parameters specify the coefficients of the elliptic		a, b: These parameters specify the coefficients of the elliptic
	curve. Each value contains the byte string representation of a		curve. Each value contains the byte string representation of a
	field element following the conversion routine in Section 4.3.3 of		field element following the conversion routine in Section 4.3.3 of
	ANSI X9.62 [6].		ANSI X9.62 [6].
	struct {		struct {
	opaque point <1..2^8-1>;		opaque point <1..2^8-1>;
	} ECPoint;		} ECPoint;
	point: This is the byte string representation of an elliptic curve		point: This is the byte string representation of an elliptic curve
	point following the conversion routine in Section 4.3.6 of ANSI		point following the conversion routine in Section 4.3.6 of ANSI
	X9.62 [6]. Note that this byte string may represent an elliptic		X9.62 [6]. This byte string may represent an elliptic curve point
	curve point in compressed or uncompressed form.		in uncompressed, hybrid, or compressed format; it MUST conform to
			what the client has requested through a Supported Point Formats
			Extension if this extension was used.
	enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;		enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
	ec_basis_trinomial: Indicates representation of a characteristic-2		ec_basis_trinomial: Indicates representation of a characteristic-2
	field using a trinomial basis.		field using a trinomial basis.
	ec_basis_pentanomial: Indicates representation of a characteristic-2		ec_basis_pentanomial: Indicates representation of a characteristic-2
	field using a pentanomial basis.		field using a pentanomial basis.
	struct {		struct {
	ECCurveType curve_type;		ECCurveType curve_type;
	select (curve_type) {		select (curve_type) {
	case explicit_prime:		case explicit_prime:
	opaque prime_p <1..2^8-1>;		opaque prime_p <1..2^8-1>;
	ECCurve curve;		ECCurve curve;
	ECPoint base;		ECPoint base;
	skipping to change at page 19, line 6 ¶		skipping to change at page 20, line 9 ¶
	opaque cofactor <1..2^8-1>;		opaque cofactor <1..2^8-1>;
	case named_curve:		case named_curve:
	NamedCurve namedcurve;		NamedCurve namedcurve;
	};		};
	} ECParameters;		} ECParameters;
	curve_type: This identifies the type of the elliptic curve domain		curve_type: This identifies the type of the elliptic curve domain
	parameters.		parameters.
	prime_p: This is the odd prime defining the field Fp.		prime_p: This is the odd prime defining the field Fp.
	curve: Specifies the coefficients a and b of the elliptic curve E.		curve: Specifies the coefficients a and b of the elliptic curve E.
	base: Specifies the base point G on the elliptic curve.		base: Specifies the base point G on the elliptic curve.
	order: Specifies the order n of the base point.		order: Specifies the order n of the base point.
	cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)		cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
	represents the number of points on the elliptic curve E defined		represents the number of points on the elliptic curve E defined
	over the field Fq.		over the field Fq (either Fp or F2^m).
	m: This is the degree of the characteristic-2 field F2^m.		m: This is the degree of the characteristic-2 field F2^m.
	k: The exponent k for the trinomial basis representation x^m + x^k		k: The exponent k for the trinomial basis representation x^m + x^k
	+1.		+1.
	k1, k2, k3: The exponents for the pentanomial representation x^m +		k1, k2, k3: The exponents for the pentanomial representation x^m +
	x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).		x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
	namedcurve: Specifies a recommended set of elliptic curve domain		namedcurve: Specifies a recommended set of elliptic curve domain
	parameters. All enum values of NamedCurve are allowed except for		parameters. All enum values of NamedCurve are allowed except for
	arbitrary_explicit_prime_curves(253) and		arbitrary_explicit_prime_curves(253) and
	arbitrary_explicit_char2_curves(254). These two values are only		arbitrary_explicit_char2_curves(254). These two values are only
	allowed in the ClientHello extension.		allowed in the ClientHello extension.
	struct {		struct {
	ECParameters curve_params;		ECParameters curve_params;
	ECPoint public;		ECPoint public;
	} ServerECDHParams;		} ServerECDHParams;
	skipping to change at page 19, line 47 ¶		skipping to change at page 21, line 16 ¶
	an ECDH public key.		an ECDH public key.
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case ec_diffie_hellman:		case ec_diffie_hellman:
	ServerECDHParams params;		ServerECDHParams params;
	Signature signed_params;		Signature signed_params;
	} ServerKeyExchange;		} ServerKeyExchange;
	params: Specifies the ECDH public key and associated domain		params: Specifies the ECDH public key and associated domain
	parameters.		parameters.
	signed_params: A hash of the params, with the signature appropriate		signed_params: A hash of the params, with the signature appropriate
	to that hash applied. The private key corresponding to the		to that hash applied. The private key corresponding to the
	certified public key in the server's Certificate message is used		certified public key in the server's Certificate message is used
	for signing.		for signing.
	enum { ecdsa } SignatureAlgorithm;		enum { ecdsa } SignatureAlgorithm;
	select (SignatureAlgorithm) {		select (SignatureAlgorithm) {
	case ecdsa:		case ecdsa:
	digitally-signed struct {		digitally-signed struct {
	opaque sha_hash[sha_size];		opaque sha_hash[sha_size];
	};		};
	} Signature;		} Signature;
	NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange		NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
	algorithm and 'anonymous' for ECDH_anon. These cases are defined in		algorithm and "anonymous" for ECDH_anon. These cases are defined in
	TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA		TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA
	signatures are generated and verified as described in Section 5.10.		signatures are generated and verified as described in Section 5.10.
	As per ANSI X9.62, an ECDSA signature consists of a pair of integers		As per ANSI X9.62, an ECDSA signature consists of a pair of integers
	r and s. These integers are both converted into byte strings of the		r and s. These integers are both converted into byte strings of the
	same length as the curve order n using the conversion routine		same length as the curve order n using the conversion routine
	specified in Section 4.3.1 of [6]. The two byte strings are		specified in Section 4.3.1 of [6]. The two byte strings are
	concatenated, and the result is placed in the signature field.		concatenated, and the result is placed in the signature field.
	Actions of the sender:		Actions of the sender:
	The server selects elliptic curve domain parameters and an ephemeral		The server selects elliptic curve domain parameters and an ephemeral
	skipping to change at page 20, line 51 ¶		skipping to change at page 22, line 25 ¶
	Meaning of this message:		Meaning of this message:
	The server uses this message to suggest acceptable client		The server uses this message to suggest acceptable client
	authentication methods.		authentication methods.
	Structure of this message:		Structure of this message:
	The TLS CertificateRequest message is extended as follows.		The TLS CertificateRequest message is extended as follows.
	enum {		enum {
	ecdsa_sign(?), rsa_fixed_ecdh(?),		ecdsa_sign(??), rsa_fixed_ecdh(??),
	ecdsa_fixed_ecdh(?), (255)		ecdsa_fixed_ecdh(??), (255)
	} ClientCertificateType;		} ClientCertificateType;
	ecdsa_sign, etc Indicates that the server would like to use the		ecdsa_sign, etc Indicates that the server would like to use the
	corresponding client authentication method specified in Section 3.		corresponding client authentication method specified in Section 3.
	EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
	ecdsa_fixed_ecdh have been left as ?. These values will be		[[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
			ecdsa_fixed_ecdh have been left as ??. These values will be
	assigned when this draft progresses to RFC. Earlier versions of		assigned when this draft progresses to RFC. Earlier versions of
	this draft used the values 5, 6, and 7 - however these values have		this draft used the values 5, 6, and 7 - however these values have
	been removed since they are used differently by SSL 3.0 [13] and		been removed since they are used differently by SSL 3.0 [14] and
	their use by TLS is being deprecated.		their use by TLS is being deprecated. ]]
	Actions of the sender:		Actions of the sender:
	The server decides which client authentication methods it would like		The server decides which client authentication methods it would like
	to use, and conveys this information to the client using the format		to use, and conveys this information to the client using the format
	defined above.		defined above.
	Actions of the receiver:		Actions of the receiver:
	The client determines whether it has an appropriate certificate for		The client determines whether it has a suitable certificate for use
	use with any of the requested methods, and decides whether or not to		with any of the requested methods, and decides whether or not to
	proceed with client authentication.		proceed with client authentication.
	5.6 Client Certificate		5.6 Client Certificate
	When this message is sent:		When this message is sent:
	This message is sent in response to a CertificateRequest when a		This message is sent in response to a CertificateRequest when a
	client has a suitable certificate.		client has a suitable certificate and has decided to proceed with
			client authentication. (Note that if the server has used a Supported
			Point Formats Extension, a certificate can only be considered
			suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and
			ECDSA_fixed_ECDH authentication methods if the public key point
			specified in it respects the server's choice of point formats. If no
			Supported Point Formats Extension has been used, a certificate can
			only be considered suitable for use with these authentication methods
			if the point is represented in uncompressed point format.)
	Meaning of this message:		Meaning of this message:
	This message is used to authentically convey the client's static		This message is used to authentically convey the client's static
	public key to the server. The following table summarizes what client		public key to the server. The following table summarizes what client
	certificate types are appropriate for the ECC-based client		certificate types are appropriate for the ECC-based client
	authentication mechanisms described in Section 3. ECC public keys		authentication mechanisms described in Section 3. ECC public keys
	must be encoded in certificates as described in Section 5.9.		must be encoded in certificates as described in Section 5.9.
	NOTE: The client's Certificate message is capable of carrying a chain		NOTE: The client's Certificate message is capable of carrying a chain
	skipping to change at page 23, line 13 ¶		skipping to change at page 24, line 41 ¶
	Meaning of the message:		Meaning of the message:
	This message is used to convey ephemeral data relating to the key		This message is used to convey ephemeral data relating to the key
	exchange belonging to the client (such as its ephemeral ECDH public		exchange belonging to the client (such as its ephemeral ECDH public
	key).		key).
	Structure of this message:		Structure of this message:
	The TLS ClientKeyExchange message is extended as follows.		The TLS ClientKeyExchange message is extended as follows.
	enum { yes, no } EphemeralPublicKey;		enum { implicit, explicit } PublicValueEncoding;
	yes, no: Indicates whether or not the client is providing an
	ephemeral ECDH public key. (In ECC ciphersuites, this is "yes"
	except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH
	client authentication mechanism.)
			implicit, explicit: For ECC cipher suites, this indicates whether
			the client's ECDH public key is in the client's certificate
			("implicit") or is provided, as an ephemeral ECDH public key, in
			the ClientKeyExchange message ("explicit"). (This is "explicit"
			in ECC cipher suites except when the client uses the
			ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
			mechanism.)
	struct {		struct {
	select (EphemeralPublicKey) {		select (PublicValueEncoding) {
	case yes: ECPoint ecdh_Yc;		case implicit: struct { };
	case no: struct { };		case explicit: ECPoint ecdh_Yc;
	} ecdh_public;		} ecdh_public;
	} ClientECDiffieHellmanPublic;		} ClientECDiffieHellmanPublic;
	ecdh_Yc: Contains the client's ephemeral ECDH public key.		ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte
			string ECPoint.point, which may represent an elliptic curve point
			in uncompressed, hybrid, or compressed format. Here the format
			MUST conform to what the server has requested through a Supported
			Point Formats Extension if this extension was used, and MUST be
			uncompressed if this extension was not used.
	struct {		struct {
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case ec_diffie_hellman: ClientECDiffieHellmanPublic;		case ec_diffie_hellman: ClientECDiffieHellmanPublic;
	} exchange_keys;		} exchange_keys;
	} ClientKeyExchange;		} ClientKeyExchange;
	Actions of the sender:		Actions of the sender:
	The client selects an ephemeral ECDH public key corresponding to the		The client selects an ephemeral ECDH public key corresponding to the
	skipping to change at page 24, line 4 ¶		skipping to change at page 25, line 42 ¶
	The server retrieves the client's ephemeral ECDH public key from the		The server retrieves the client's ephemeral ECDH public key from the
	ClientKeyExchange message and checks that it is on the same elliptic		ClientKeyExchange message and checks that it is on the same elliptic
	curve as the server's ECDH key.		curve as the server's ECDH key.
	5.8 Certificate Verify		5.8 Certificate Verify
	When this message is sent:		When this message is sent:
	This message is sent when the client sends a client certificate		This message is sent when the client sends a client certificate
	containing a public key usable for digital signatures, e.g. when the		containing a public key usable for digital signatures, e.g. when the
	client is authenticated using the ECDSA_sign mechanism.		client is authenticated using the ECDSA_sign mechanism.
	Meaning of the message:		Meaning of the message:
	This message contains a signature that proves possession of the		This message contains a signature that proves possession of the
	private key corresponding to the public key in the client's		private key corresponding to the public key in the client's
	Certificate message.		Certificate message.
	Structure of this message:		Structure of this message:
	skipping to change at page 25, line 18 ¶		skipping to change at page 27, line 6 ¶
	MUST comply with [11] or another RFC that replaces or extends it.		MUST comply with [11] or another RFC that replaces or extends it.
	Clients SHOULD use the elliptic curve domain parameters recommended		Clients SHOULD use the elliptic curve domain parameters recommended
	in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].		in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
	5.10 ECDH, ECDSA and RSA Computations		5.10 ECDH, ECDSA and RSA Computations
	All ECDH calculations (including parameter and key generation as well		All ECDH calculations (including parameter and key generation as well
	as the shared secret calculation) MUST be performed according to [5]		as the shared secret calculation) MUST be performed according to [5]
	using the ECKAS-DH1 scheme with the identity map as key derivation		using the ECKAS-DH1 scheme with the identity map as key derivation
	function, so that the premaster secret is the x-coordinate of the		function, so that the premaster secret is the x-coordinate of the
	ECDH shared secret elliptic curve point, i.e. the octet string Z in		ECDH shared secret elliptic curve point, i.e. the octet string Z in
	IEEE 1363 terminology.		IEEE 1363 terminology.
	Note that a new extension may be introduced in the future to allow		Note that a new extension may be introduced in the future to allow
	the use of a different KDF during computation of the premaster		the use of a different KDF during computation of the premaster
	secret. In this event, the new KDF would be used in place of the		secret. In this event, the new KDF would be used in place of the
	process detailed above. This may be desirable, for example, to		process detailed above. This may be desirable, for example, to
	support compatibility with the planned NIST key agreement standard.		support compatibility with the planned NIST key agreement standard.
	All ECDSA computations MUST be performed according to ANSI X9.62 [6]		All ECDSA computations MUST be performed according to ANSI X9.62 [6]
	or its successors. Data to be signed/verified is hashed and the		or its successors. Data to be signed/verified is hashed and the
	skipping to change at page 25, line 42 ¶		skipping to change at page 27, line 30 ¶
	function, such as one of the new SHA hash functions specified in FIPS		function, such as one of the new SHA hash functions specified in FIPS
	180-2 [7], may be used instead if the certificate containing the EC		180-2 [7], may be used instead if the certificate containing the EC
	public key explicitly requires use of another hash function. (The		public key explicitly requires use of another hash function. (The
	mechanism for specifying the required hash function has not been		mechanism for specifying the required hash function has not been
	standardized but this provision anticipates such standardization and		standardized but this provision anticipates such standardization and
	obviates the need to update this document in response. Future PKIX		obviates the need to update this document in response. Future PKIX
	RFCs may choose, for example, to specify the hash function to be used		RFCs may choose, for example, to specify the hash function to be used
	with a public key in the parameters field of subjectPublicKeyInfo.)		with a public key in the parameters field of subjectPublicKeyInfo.)
	All RSA signatures must be generated and verified according to PKCS#1		All RSA signatures must be generated and verified according to PKCS#1
	[9].		[9] block type 1.
	6. Cipher Suites		6. Cipher Suites
	The table below defines new ECC cipher suites that use the key		The table below defines new ECC cipher suites that use the key
	exchange algorithms specified in Section 2.		exchange algorithms specified in Section 2.
	CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
	skipping to change at page 26, line 43 ¶		skipping to change at page 28, line 43 ¶
	CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
	Table 5: TLS ECC cipher suites		Table 5: TLS ECC cipher suites
	Figure 30		[[ EDITOR: The actual cipher suite numbers will be assigned when this
			draft progresses to RFC. ]]
	The key exchange method, cipher, and hash algorithm for each of these		The key exchange method, cipher, and hash algorithm for each of these
	cipher suites are easily determined by examining the name. Ciphers		cipher suites are easily determined by examining the name. Ciphers
	other than AES ciphers, and hash algorithms are defined in [2]. AES		other than AES ciphers, and hash algorithms are defined in [2]. AES
	ciphers are defined in [14].		ciphers are defined in [15].
	Server implementations SHOULD support all of the following cipher		Server implementations SHOULD support all of the following cipher
	suites, and client implementations SHOULD support at least one of		suites, and client implementations SHOULD support at least one of
	them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,		them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,		TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and		TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.		TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
	7. Security Considerations		7. Security Considerations
	This document is based on [2], [5], [6] and [14]. The appropriate		This document is based on [2], [5], [6] and [15]. The appropriate
	security considerations of those documents apply.		security considerations of those documents apply.
	One important issue that implementors and users must consider is		One important issue that implementors and users must consider is
	elliptic curve selection. Guidance on selecting an appropriate		elliptic curve selection. Guidance on selecting an appropriate
	elliptic curve size is given in Figure 1.		elliptic curve size is given in Table 1.
	Beyond elliptic curve size, the main issue is elliptic curve		Beyond elliptic curve size, the main issue is elliptic curve
	structure. As a general principle, it is more conservative to use		structure. As a general principle, it is more conservative to use
	elliptic curves with as little algebraic structure as possible - thus		elliptic curves with as little algebraic structure as possible - thus
	random curves are more conservative than special curves such as		random curves are more conservative than special curves such as
	Koblitz curves, and curves over F_p with p random are more		Koblitz curves, and curves over F_p with p random are more
	conservative than curves over F_p with p of a special form (and		conservative than curves over F_p with p of a special form (and
	curves over F_p with p random might be considered more conservative		curves over F_p with p random might be considered more conservative
	than curves over F_2^m as there is no choice between multiple fields		than curves over F_2^m as there is no choice between multiple fields
	of similar size for characteristic 2). Note, however, that algebraic		of similar size for characteristic 2). Note, however, that algebraic
	skipping to change at page 30, line 15 ¶		skipping to change at page 32, line 15 ¶
	9. References		9. References
	9.1 Normative References		9.1 Normative References
	[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement		[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and		[3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
	T. Wright, "Transport Layer Security (TLS) Extensions",		T. Wright, "Transport Layer Security (TLS) Extensions",
	Internet-draft draft-ietf-tls-rfc3546bis-00.txt, Nov. 2004.		draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004.
	[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,		[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
	<http://www.secg.org/>.		<http://www.secg.org/>.
	[5] IEEE, "Standard Specifications for Public Key Cryptography",		[5] IEEE, "Standard Specifications for Public Key Cryptography",
	IEEE 1363, 2000.		IEEE 1363, 2000.
	[6] ANSI, "Public Key Cryptography For The Financial Services		[6] ANSI, "Public Key Cryptography For The Financial Services
	Industry: The Elliptic Curve Digital Signature Algorithm		Industry: The Elliptic Curve Digital Signature Algorithm
	(ECDSA)", ANSI X9.62, 1998.		(ECDSA)", ANSI X9.62, 1998.
	skipping to change at page 30, line 39 ¶		skipping to change at page 32, line 39 ¶
	[7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.		[7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
	[8] NIST, "Digital Signature Standard", FIPS 186-2, 2000.		[8] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
	[9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version		[9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
	1.5", PKCS 1, November 1993.		1.5", PKCS 1, November 1993.
	[10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,		[10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
	2000, <http://www.secg.org/>.		2000, <http://www.secg.org/>.
	[11] Polk, T., Housley, R. and L. Bassham, "Algorithms and		[11] Polk, T., Housley, R., and L. Bassham, "Algorithms and
	Identifiers for the Internet X.509 Public Key Infrastructure		Identifiers for the Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL) Profile",		Certificate and Certificate Revocation List (CRL) Profile",
	RFC 3279, April 2002.		RFC 3279, April 2002.
	9.2 Informative References		9.2 Informative References
	[12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key		[12] Harper, G., Menezes, A., and S. Vanstone, "Public-Key
			Cryptosystems with Very Small Key Lengths", Advances in
			Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
			[13] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
	Sizes", Journal of Cryptology 14 (2001) 255-293,		Sizes", Journal of Cryptology 14 (2001) 255-293,
	<http://www.cryptosavvy.com/>.		<http://www.cryptosavvy.com/>.
	[13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol		[14] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
	Version 3.0", November 1996,		Version 3.0", November 1996,
	<http://wp.netscape.com/eng/ssl3/draft302.txt>.		<http://wp.netscape.com/eng/ssl3/draft302.txt>.
	[14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for		[15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
	Transport Layer Security (TLS)", RFC 3268, June 2002.		Transport Layer Security (TLS)", RFC 3268, June 2002.
	[15] Hovey, R. and S. Bradner, "The Organizations Involved in the
	IETF Standards Process", RFC 2028, BCP 11, October 1996.
	Authors' Addresses		Authors' Addresses
	Vipul Gupta		Vipul Gupta
	Sun Microsystems Laboratories		Sun Microsystems Laboratories
	16 Network Circle		16 Network Circle
	MS UMPK16-160		MS UMPK16-160
	Menlo Park, CA 94025		Menlo Park, CA 94025
	USA		US
	Phone: +1 650 786 7551		Phone: +1 650 786 7551
	Email: vipul.gupta@sun.com		Email: vipul.gupta@sun.com
	Simon Blake-Wilson		Simon Blake-Wilson
	Basic Commerce & Industries, Inc.		Basic Commerce & Industries, Inc.
	96 Spandia Ave		96 Spandia Ave
	Unit 606		Unit 606
	Toronto, ON M6G 2T6		Toronto, ON M6G 2T6
	Canada		CA
	Phone: +1 416 214 5961		Phone: +1 416 214 5961
	Email: sblakewilson@bcisse.com		Email: sblakewilson@bcisse.com
	Bodo Moeller		Bodo Moeller
	University of Calgary		University of Calgary
	Dept of Math & Stats		Dept of Math & Stats
	2500 University Dr NW		2500 University Dr NW
	Calgary, AB T2N 1N4		Calgary, AB T2N 1N4
	CA		CA
			Phone: +1 403 220 5735
	Email: bodo@openssl.org		Email: bodo@openssl.org
	Chris Hawk		Chris Hawk
	Corriente Networks		Corriente Networks
	Email: chris@corriente.net		Email: chris@corriente.net
	Nelson Bolyard		Nelson Bolyard
	Email: nelson@bolyard.com		Email: nelson@bolyard.com
End of changes. 97 change blocks.
	164 lines changed or deleted		249 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/