< draft-ietf-tls-ecc-06.txt		draft-ietf-tls-ecc-07.txt >
	TLS Working Group V. Gupta		TLS Working Group V. Gupta
	Internet-Draft Sun Labs		Internet-Draft Sun Labs
	Expires: October 30, 2004 S. Blake-Wilson		Expires: June 1, 2005 S. Blake-Wilson
	BCI		BCI
	B. Moeller		B. Moeller
	University of California, Berkeley		University of California, Berkeley
	C. Hawk		C. Hawk
	Independent Consultant		Corriente Networks
	N. Bolyard		N. Bolyard
	Netscape		Dec. 2004
	May. 2004
	ECC Cipher Suites for TLS		ECC Cipher Suites for TLS
	<draft-ietf-tls-ecc-06.txt>		<draft-ietf-tls-ecc-07.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is subject to all provisions
	all provisions of Section 10 of RFC2026.		of section 3 of RFC 3667. By submitting this Internet-Draft, each
			author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
			RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		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 Internet-		other groups may also distribute working documents as
	Drafts.		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 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 http://		The list of current Internet-Drafts can be accessed at
	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 October 30, 2004.		This Internet-Draft will expire on June 1, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	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
	Elliptic Curve Digital Signature Algorithm (ECDSA) as a new		Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
	authentication mechanism.		authentication mechanism.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8
	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 Extensions . . . . . . . . . . . . . . . . . 15
	5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 16		5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16
	5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 17		5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17
	5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 21		5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20
	5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21		5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21
	5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 23		5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22
	5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24		5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23
	5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . . 25		5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25
	5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . 25		5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25
	6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 27		6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . 28
	8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	Normative References . . . . . . . . . . . . . . . . . . . . 32		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
	Informative References . . . . . . . . . . . . . . . . . . . 33		9.2 Informative References . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 35		Intellectual Property and Copyright Statements . . . . . . . 33
	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 [12], 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, Section 8 and		implementations of this specification. Section 7 and Section 8
	Section 9 mention security considerations, intellectual property		mention security considerations and acknowledgments, respectively.
	rights, and acknowledgments, respectively. This is followed by a		This is followed by a list of references cited in this document, the
	list of references cited in this document and the authors' contact		authors' contact information, and statements on intellectual property
	information.		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, DH_RSA, DHE_DSS, 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 13 ¶		skipping to change at page 6, line 14 ¶
	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 ECDH-		to certain computations. This document refers to an ECC key as
	capable if its use in ECDH is permitted. ECDSA-capable is defined		ECDH-capable if its use in ECDH is permitted. ECDSA-capable is
	similarly.		defined similarly.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	Certificate*		Certificate*
	ServerKeyExchange*		ServerKeyExchange*
	CertificateRequest*+		CertificateRequest*+
	<-------- ServerHelloDone		<-------- ServerHelloDone
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 42 ¶
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Figure 1: Message flow in a full TLS handshake		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 the client is
	authenticated		authenticated
			Figure 3
	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 Figure
	1) until Section 3 and of the optional ECC-specific extensions (which		1) until Section 3 and of the optional ECC-specific extensions (which
	impact the Hello messages) until Section 4.		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).
	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 long-term public key and send its public key in the		server's long-term public key and send its public key in the
	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 ECDSA-		In ECDHE_ECDSA, the server's certificate MUST contain an
	capable public key and be signed with ECDSA.		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.
	Both client and server MUST perform an ECDH operation (Section 5.10)		Both client and server MUST perform an ECDH operation (Section 5.10)
	and use the resultant shared secret as the premaster secret.		and use the resultant shared secret as the premaster secret.
	2.3 ECDH_RSA		2.3 ECDH_RSA
	This key exchange algorithm is the same as ECDH_ECDSA except the		This key exchange algorithm is the same as ECDH_ECDSA except the
	server's certificate MUST be signed with RSA rather than ECDSA.		server's certificate MUST be signed with RSA rather than ECDSA.
	2.4 ECDHE_RSA		2.4 ECDHE_RSA
	This key exchange algorithm is the same as ECDHE_ECDSA except the		This key exchange algorithm is the same as ECDHE_ECDSA except the
	server's certificate MUST contain an RSA public key authorized for		server's certificate MUST contain an RSA public key authorized for
	signing and the signature in the ServerKeyExchange message MUST be		signing and the signature in the ServerKeyExchange message MUST be
	computed with the corresponding RSA private key. The server		computed with the corresponding RSA private key. The server
	certificate MUST be signed with RSA.		certificate MUST be signed with RSA.
	2.5 ECDH_anon		2.5 ECDH_anon
	In ECDH_anon, the server's Certificate, the CertificateRequest, the		In ECDH_anon, the server's Certificate, the CertificateRequest, the
	client's Certificate, and the CertificateVerify messages MUST NOT be		client's Certificate, and the CertificateVerify messages MUST NOT be
	sent.		sent.
	The server MUST send an ephemeral ECDH public key and a specification		The server MUST send an ephemeral ECDH public key and a specification
	of the corresponding curve in the ServerKeyExchange message. These		of the corresponding curve in the ServerKeyExchange message. These
	parameters MUST NOT be signed.		parameters MUST NOT be signed.
	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.
	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
	3. Client Authentication		3. Client Authentication
	This document defines three new client authentication mechanisms		This document defines three new client authentication mechanisms
	named after the type of client certificate involved: ECDSA_sign,		named after the type of client certificate involved: ECDSA_sign,
	ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is		ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is
	usable with any of the non-anonymous ECC key exchange algorithms		usable with any of the non-anonymous ECC key exchange algorithms
	described in Section 2 as well as other non-anonymous (non-ECC) key		described in Section 2 as well as other non-anonymous (non-ECC) key
	exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and		exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and
	RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.		RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
	Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the		Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
	use of a long-term ECDH client key would jeopardize the forward		use of a long-term ECDH client key would jeopardize the forward
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	for authentication, it MUST send that certificate in the client's		for authentication, it MUST send that certificate in the client's
	Certificate message (as per Section 5.6) and prove possession of the		Certificate message (as per Section 5.6) and prove possession of the
	private key corresponding to the certified key. The process of		private key corresponding to the certified key. The process of
	determining an appropriate certificate and proving possession is		determining an appropriate certificate and proving possession is
	different for each authentication mechanism and described below.		different for each authentication mechanism and described below.
	NOTE: It is permissible for a server to request (and the client to		NOTE: It is permissible for a server to request (and the client to
	send) a client certificate of a different type than the server		send) a client certificate of a different type than the server
	certificate.		certificate.
	3.1 ECDSA_sign		3.1 ECDSA_sign
	To use this authentication mechanism, the client MUST possess a		To use this authentication mechanism, the client MUST possess a
	certificate containing an ECDSA-capable public key and signed with		certificate containing an ECDSA-capable public key and signed with
	ECDSA.		ECDSA.
	The client MUST prove possession of the private key corresponding to		The client MUST prove possession of the private key corresponding to
	the certified key by including a signature in the CertificateVerify		the certified key by including a signature in the CertificateVerify
	message as described in Section 5.8.		message as described in Section 5.8.
	3.2 ECDSA_fixed_ECDH		3.2 ECDSA_fixed_ECDH
	To use this authentication mechanism, the client MUST possess a		To use this authentication mechanism, the client MUST possess a
	certificate containing an ECDH-capable public key and that		certificate containing an ECDH-capable public key and that
	certificate MUST be signed with ECDSA. Furthermore, the client's		certificate MUST be signed with ECDSA. Furthermore, the client's
	ECDH key MUST be on the same elliptic curve as the server's long-term		ECDH key MUST be on the same elliptic curve as the server's long-term
	(certified) ECDH key. This might limit use of this mechanism to		(certified) ECDH key. This might limit use of this mechanism to
	closed environments. In situations where the client has an ECC key		closed environments. In situations where the client has an ECC key
	on a different curve, it would have to authenticate either using		on a different curve, it would have to authenticate either using
	ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for		ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for
	both servers and clients is computationally more efficient than		both servers and clients is computationally more efficient than
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 28 ¶
	When using this authentication mechanism, the client MUST send an		When using this authentication mechanism, the client MUST send an
	empty ClientKeyExchange as described in Section 5.7 and MUST NOT send		empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
	the CertificateVerify message. The ClientKeyExchange is empty since		the CertificateVerify message. The ClientKeyExchange is empty since
	the client's ECDH public key required by the server to compute the		the client's ECDH public key required by the server to compute the
	premaster secret is available inside the client's certificate. The		premaster secret is available inside the client's certificate. The
	client's ability to arrive at the same premaster secret as the server		client's ability to arrive at the same premaster secret as the server
	(demonstrated by a successful exchange of Finished messages) proves		(demonstrated by a successful exchange of Finished messages) proves
	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 --- (i) the Supported Elliptic Curves
	Extension, and (ii) the Supported Point Formats Extension --- allow a		Extension, and (ii) the Supported Point Formats Extension --- allow a
	client to negotiate the use of specific curves and point formats		client to negotiate the use of specific curves and point formats
	(e.g. compressed v/s uncompressed), respectively. These extensions		(e.g. compressed v/s uncompressed), respectively. These extensions
	are especially relevant for constrained clients that may only support		are especially relevant for constrained clients that may only support
	a limited number of curves or point formats. They follow the		a limited number of curves or point formats. They follow the general
	general approach outlined in [3]. The client enumerates the curves		approach outlined in [3]. The client enumerates the curves and point
	and point formats it supports by including the appropriate extensions		formats it supports by including the appropriate extensions in its
	in its ClientHello message. By echoing that extension in its		ClientHello message. By echoing that extension in its ServerHello,
	ServerHello, the server agrees to restrict its key selection or		the server agrees to restrict its key selection or encoding to the
	encoding to the choices specified by the client.		choices specified by the client.
	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 negotiate the use of
	an ECC cipher suite only if they can complete the handshake while		an ECC cipher suite only if they can complete the handshake while
	limiting themselves to the curves and compression techniques		limiting themselves to the curves and compression techniques
	enumerated by the client. This eliminates the possibility that a		enumerated by the client. This eliminates the possibility that a
	negotiated ECC handshake will be subsequently aborted due to a		negotiated ECC handshake will be subsequently aborted due to a
	client's inability to deal with the server's EC key.		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.
	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:		When this message is sent:
	The ECC extensions SHOULD be sent along with any ClientHello message		The ECC extensions SHOULD be sent along with any ClientHello message
	that proposes ECC cipher suites.		that proposes ECC cipher suites.
	Meaning of this message:		Meaning of this message:
	These extensions allow a constrained client to enumerate the elliptic		These extensions allow a constrained client to enumerate the elliptic
	curves and/or point formats it supports.		curves and/or point formats it supports.
	Structure of this message:		Structure of this message:
	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(6), ec_point_formats(7) } ExtensionType;		enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
	elliptic_curves: Indicates the set of elliptic curves supported by		elliptic_curves: Indicates the set of elliptic curves supported by
	the client. For this extension, the opaque extension_data field		the client. For this extension, the opaque extension_data field
	contains EllipticCurveList.		contains EllipticCurveList.
	ec_point_formats: Indicates the set of point formats supported by		ec_point_formats: Indicates the set of point formats supported by
	the client. For this extension, the opaque extension_data field		the client. For this extension, the opaque extension_data field
	contains ECPointFormatList.		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),
	skipping to change at page 13, line 39 ¶		skipping to change at page 13, line 39 ¶
	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		and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
	include an elliptic_curves extension with the following octets:		include an elliptic_curves extension with the following octets:
	00 06 02 13 15		00 ?? 02 13 15
	A client that supports arbitrary explicit binary polynomial curves		A client that supports arbitrary explicit binary polynomial curves
	would include an extension with the following octets:		would include an extension with the following octets:
	00 06 01 fe		00 ?? 01 fe
	enum { uncompressed (0), ansiX963_compressed (1),		enum { uncompressed (0), ansiX963_compressed (1),
	ansiX963_hybrid (2), (255)		ansiX963_hybrid (2), (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 defintion of ECPointFormat
	above. The uncompressed point format is the default format that		above. The uncompressed point format is the default format that
	implementations of this document MUST support. The		implementations of this document MUST support. The
	ansix963_compressed format reduces bandwidth by including only the x-		ansix963_compressed format reduces bandwidth by including only the
	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		ansix963_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.		ansix963_compressed and ansix963_hybrid point formats.
	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 only supports the uncompressed point format includes an
	extension with the following octets:		extension with the following octets:
	00 07 01 00		00 ?? 01 00
	A client that prefers the use of the ansiX963_compressed format over		A client that prefers the use of the ansiX963_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:		with the following octets:
	00 07 02 01 00		00 ?? 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 appends
	these extensions (along with any others) enumerating the curves and		these extensions (along with any others) enumerating the curves and
	point formats it supports.		point formats it supports.
	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
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 16 ¶
	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 Extensions
	When this message is sent:		When this message is sent:
	The ServerHello ECC extensions are sent in response to a Client Hello		The ServerHello ECC extensions are sent in response to a Client Hello
	message containing ECC extensions when negotiating an ECC cipher		message containing ECC extensions when negotiating an ECC cipher
	suite.		suite.
	Meaning of this message:		Meaning of this message:
	These extensions indicate the server's agreement to use only the		These extensions indicate the server's agreement to use only the
	skipping to change at page 15, line 39 ¶		skipping to change at page 15, line 39 ¶
	Structure of this message:		Structure of this message:
	The ECC extensions echoed by the server are the same as those in the		The ECC extensions echoed by the server are the same as those in the
	ClientHello except the "extension_data" field is empty.		ClientHello except the "extension_data" field is empty.
	For example, a server indicates its acceptance of the client's		For example, a server indicates its acceptance of the client's
	elliptic_curves extension by sending an extension with the following		elliptic_curves extension by sending an extension with the following
	octets:		octets:
	00 06 00 00		00 ?? 00 00
	Actions of the sender:		Actions of the sender:
	A server makes sure that it can complete a proposed ECC key exchange		A server makes sure that it can complete a proposed ECC key exchange
	mechanism by restricting itself to the curves/point formats supported		mechanism by restricting itself to the curves/point formats supported
	by the client before sending these extensions.		by the client before sending these extensions.
	Actions of the receiver:		Actions of the receiver:
	A client that receives a ServerHello with ECC extensions proceeds		A client that receives a ServerHello with ECC extensions proceeds
	with an ECC key exchange assured that it will be able to handle the		with an ECC key exchange assured that it will be able to handle the
	server's EC key(s).		server's EC key(s).
	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:
	This message is used to authentically convey the server's static		This message is used to authentically convey the server's static
	public key to the client. The following table shows the server		public key to the client. The following table shows the server
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 14 ¶
	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.
	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:
	This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and		This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
	ECDH_anon key exchange algorithms.		ECDH_anon key exchange algorithms.
	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
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 35 ¶
	ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to		ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to
	the client in the ServerKeyExchange message using the format defined		the client in the ServerKeyExchange message using the format defined
	above.		above.
	Actions of the recipient:		Actions of the recipient:
	The client verifies the signature (when present) and retrieves the		The client verifies the signature (when present) and retrieves the
	server's elliptic curve domain parameters and ephemeral ECDH public		server's elliptic curve domain parameters and ephemeral ECDH public
	key from the ServerKeyExchange message.		key from the ServerKeyExchange message.
	5.5 Certificate Request		5.5 Certificate Request
	When this message is sent:		When this message is sent:
	This message is sent when requesting client authentication.		This message is sent when requesting client authentication.
	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.
	skipping to change at page 21, line 27 ¶		skipping to change at page 21, line 9 ¶
	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		EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
	ecdsa_fixed_ecdh have been left as ?. These values will be		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 [13] 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 an appropriate certificate for
	use with any of the requested methods, and decides whether or not to		use 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.
	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
	skipping to change at page 23, line 7 ¶		skipping to change at page 22, line 42 ¶
	The client constructs an appropriate certificate chain, and conveys		The client constructs an appropriate certificate chain, and conveys
	it to the server in the Certificate message.		it to the server in the Certificate message.
	Actions of the receiver:		Actions of the receiver:
	The TLS server validates the certificate chain, extracts the client's		The TLS server validates the certificate chain, extracts the client'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
	client authentication method.		client authentication method.
	5.7 Client Key Exchange		5.7 Client Key Exchange
	When this message is sent:		When this message is sent:
	This message is sent in all key exchange algorithms. If client		This message is sent in all key exchange algorithms. If client
	authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this		authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
	message is empty. Otherwise, it contains the client's ephemeral ECDH		message is empty. Otherwise, it contains the client's ephemeral ECDH
	public key.		public key.
	Meaning of the message:		Meaning of the message:
	skipping to change at page 24, line 16 ¶		skipping to change at page 23, line 48 ¶
	parameters it received from the server according to the ECKAS-DH1		parameters it received from the server according to the ECKAS-DH1
	scheme from IEEE 1363 [5]. It conveys this information to the client		scheme from IEEE 1363 [5]. It conveys this information to the client
	in the ClientKeyExchange message using the format defined above.		in the ClientKeyExchange message using the format defined above.
	Actions of the recipient:		Actions of the recipient:
	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
	skipping to change at page 25, line 19 ¶		skipping to change at page 25, line 5 ¶
	message. It uses the private key corresponding to its certified		message. It uses the private key corresponding to its certified
	public key to compute the signature which is conveyed in the format		public key to compute the signature which is conveyed in the format
	defined above.		defined above.
	Actions of the receiver:		Actions of the receiver:
	The server extracts the client's signature from the CertificateVerify		The server extracts the client's signature from the CertificateVerify
	message, and verifies the signature using the public key it received		message, and verifies the signature using the public key it received
	in the client's Certificate message.		in the client's Certificate message.
	5.9 Elliptic Curve Certificates		5.9 Elliptic Curve Certificates
	X509 certificates containing ECC public keys or signed using ECDSA		X509 certificates containing ECC public keys or signed using ECDSA
	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
	skipping to change at page 27, line 5 ¶		skipping to change at page 26, line 5 ¶
	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].
	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?? }
	CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
	skipping to change at page 27, line 43 ¶		skipping to change at page 26, 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
	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 [14].
	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 [14]. 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 Figure 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
	skipping to change at page 30, line 5 ¶		skipping to change at page 29, line 5 ¶
	of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.		of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
	Similarly if the client is providing a static, certified key,		Similarly if the client is providing a static, certified key,
	ECDSA_sign client authentication provides forward secrecy protection		ECDSA_sign client authentication provides forward secrecy protection
	in the event of client key compromise, while ECDSA_fixed_ECDH and		in the event of client key compromise, while ECDSA_fixed_ECDH and
	RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy		RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy
	protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,		protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
	with ECDSA_sign used for client authentication if necessary. Here		with ECDSA_sign used for client authentication if necessary. Here
	again the security benefits of forward secrecy may need to be		again the security benefits of forward secrecy may need to be
	balanced against the improved efficiency offered by other options.		balanced against the improved efficiency offered by other options.
	8. Intellectual Property Rights		8. Acknowledgments
	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 [15]. 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.
	9. Acknowledgments
	The authors wish to thank Bill Anderson and Tim Dierks.		The authors wish to thank Bill Anderson and Tim Dierks.
	Normative References		9. 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", RFC		[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
	2246, January 1999.		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", RFC		T. Wright, "Transport Layer Security (TLS) Extensions",
	3546, June 2003.		draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004.
	[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://		[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
	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.
	[7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.		[7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
	skipping to change at page 33, line 5 ¶		skipping to change at page 30, line 44 ¶
	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", RFC		Certificate and Certificate Revocation List (CRL) Profile", RFC
	3279, April 2002.		3279, April 2002.
	Informative References		9.2 Informative References
	[12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key		[12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
	Sizes", Journal of Cryptology 14 (2001) 255-293, <http://		Sizes", Journal of Cryptology 14 (2001) 255-293,
	www.cryptosavvy.com/>.		<http://www.cryptosavvy.com/>.
	[13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol		[13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
	Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/		Version 3.0", November 1996,
	draft302.txt>.		<http://wp.netscape.com/eng/ssl3/draft302.txt>.
	[14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for		[14] 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		[15] Hovey, R. and S. Bradner, "The Organizations Involved in the
	IETF Standards Process", RFC 2028, BCP 11, October 1996.		IETF Standards Process", RFC 2028, BCP 11, October 1996.
	Authors' Addresses		Authors' Addresses
	Vipul Gupta		Vipul Gupta
	Sun Microsystems Laboratories		Sun Microsystems Laboratories
	2600 Casey Avenue		16 Network Circle
	MS UMTV29-235		MS UMPK16-160
	Mountain View, CA 94303		Menlo Park, CA 94025
	USA		USA
	Phone: +1 650 336 1681		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		Canada
	Phone: +1 416 214 5961		Phone: +1 416 214 5961
	skipping to change at page 34, line 4 ¶		skipping to change at page 31, line 32 ¶
	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		Canada
	Phone: +1 416 214 5961		Phone: +1 416 214 5961
	EMail: sblakewilson@bcisse.com		EMail: sblakewilson@bcisse.com
	Bodo Moeller		Bodo Moeller
	University of California, Berkeley		University of California, Berkeley
	EECS -- Computer Science Division		EECS -- Computer Science Division
	513 Soda Hall		513 Soda Hall
	Berkeley, CA 94720-1776		Berkeley, CA 94720-1776
	USA		USA
	EMail: bodo@openssl.org		EMail: bodo@openssl.org
	Chris Hawk		Chris Hawk
	Independent Consultant		Corriente Networks
	EMail: chris@socialeng.com
			EMail: chris@corriente.net
	Nelson Bolyard		Nelson Bolyard
	Netscape
	EMail: misterssl@aol.com		EMail: nelson@bolyard.com
	Full Copyright Statement		Intellectual Property Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	This document and translations of it may be copied and furnished to		Copies of IPR disclosures made to the IETF Secretariat and any
	others, and derivative works that comment on or otherwise explain it		assurances of licenses to be made available, or the result of an
	or assist in its implementation may be prepared, copied, published		attempt made to obtain a general license or permission for the use of
	and distributed, in whole or in part, without restriction of any		such proprietary rights by implementers or users of this
	kind, provided that the above copyright notice and this paragraph are		specification can be obtained from the IETF on-line IPR repository at
	included on all such copies and derivative works. However, this		http://www.ietf.org/ipr.
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		The IETF invites any interested party to bring to its attention any
	revoked by the Internet Society or its successors or assigns.		copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	This document and the information contained herein is provided on an		Disclaimer of Validity
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 77 change blocks.
	158 lines changed or deleted		157 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/