< draft-ietf-tls-ecc-04.txt		draft-ietf-tls-ecc-05.txt >
	TLS Working Group V. Gupta		TLS Working Group V. Gupta
	Internet-Draft Sun Labs		Internet-Draft Sun Labs
	Expires: May 1, 2004 S. Blake-Wilson		Expires: July 1, 2004 S. Blake-Wilson
	BCI		BCI
	B. Moeller		B. Moeller
	TBD		University of California, Berkeley
	C. Hawk		C. Hawk
	Independent Consultant		Independent Consultant
	N. Bolyard		N. Bolyard
	Netscape		Netscape
	Nov. 2003		Jan. 2004
	ECC Cipher Suites for TLS		ECC Cipher Suites for TLS
	<draft-ietf-tls-ecc-04.txt>		<draft-ietf-tls-ecc-05.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 in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 May 1, 2004.		This Internet-Draft will expire on July 1, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	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.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . 14		5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . . 15
	5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15		5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15
	5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 16		5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 17
	5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 20		5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 21
	5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21		5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21
	5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 22		5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 23
	5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24		5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24
	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 . . . . . . . . . . . . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . 29
	8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30		8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31
	Normative References . . . . . . . . . . . . . . . . . . . . 32		Normative References . . . . . . . . . . . . . . . . . . . . 32
	Informative References . . . . . . . . . . . . . . . . . . . 33		Informative References . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 32 ¶
	recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240		recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240
	through 247 are reserved for private use. Values 253 and 254		through 247 are reserved for private use. Values 253 and 254
	indicate that the client supports arbitrary prime and		indicate that the client supports arbitrary prime and
	charactersitic two curves, respectively (the curve parameters must		charactersitic two curves, respectively (the curve parameters must
	be encoded explicitly in ECParameters).		be encoded explicitly in ECParameters).
	struct {		struct {
	NamedCurve elliptic_curve_list<1..2^16-1>		NamedCurve elliptic_curve_list<1..2^16-1>
	} EllipticCurveList;		} EllipticCurveList;
			Items in elliptic_curve_list are ordered according to the client's
			preferences (favorite choice first).
	As an example, a client that only supports secp192r1 (aka NIST P-192)		As an example, a client that only supports secp192r1 (aka NIST P-192)
	and secp192r1 (aka NIST P-224) would include an elliptic_curves		and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
	extension with the following octets:		include an elliptic_curves extension with the following octets:
	00 06 00 02 13 14		00 06 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 00 01 fe		00 06 00 01 fe
	enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) }		enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) }
	ECPointFormat;		ECPointFormat;
	struct {		struct {
	ECPointFormat ec_point_format_list<1..2^16-1>		ECPointFormat ec_point_format_list<1..2^16-1>
	} ECPointFormatList;		} ECPointFormatList;
			Items in ec_point_format_list are ordered according to the client's
			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 00 01 00		00 07 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 00 02 01 00		00 07 00 02 01 00
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 37 ¶
	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.
	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>;
	opaque seed <0..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].
	seed: This is an optional parameter used to derive the coefficients
	of a randomly generated elliptic curve.
	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]. Note that this byte string may represent an elliptic
	curve point in compressed or uncompressed form. Implementations		curve point in compressed or uncompressed form. Implementations
	of this specification MUST support the uncompressed form and MAY		of this specification MUST support the uncompressed form and MAY
	support the compressed form.		support the compressed form.
	skipping to change at page 18, line 47 ¶		skipping to change at page 19, line 5 ¶
	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 (and optional seed) of the		curve: Specifies the coefficients a and b of the elliptic curve E.
	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.
	m: This is the degree of the characteristic-two field F2^m.		m: This is the degree of the characteristic-two field F2^m.
	skipping to change at page 25, line 14 ¶		skipping to change at page 25, line 22 ¶
	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]. Clients SHOULD use the elliptic curve domain		MUST comply with [11] or another RFC that replaces or extends it.
	parameters recommended in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2		Clients SHOULD use the elliptic curve domain parameters recommended
	[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		using
	o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation		o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation
	primitive, the KDF1 key derivation function using SHA-1 [7], and		primitive, the KDF1 key derivation function using SHA-1 [7], and
	null key derivation parameters "P" for elliptic curve parameters		null key derivation parameters "P" for elliptic curve parameters
	skipping to change at page 25, line 52 ¶		skipping to change at page 26, line 12 ¶
	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
	result run directly through the ECDSA algorithm with no additional		result run directly through the ECDSA algorithm with no additional
	hashing. The default hash function is SHA-1 [7] and sha_size (see		hashing. The default hash function is SHA-1 [7] and sha_size (see
	Section 5.4 and Section 5.8) is 20. However, an alternative hash		Section 5.4 and Section 5.8) is 20. However, an alternative hash
	function, such as one of the new SHA hash functions specified in FIPS		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.		public key explicitly requires use of another hash function. (The
			mechanism for specifying the required hash function has not been
			standardized but this provision anticipates such standardization and
			obviates the need to update this document in response. Future PKIX
			RFCs may choose, for example, to specify the hash function to be used
			with a public key in the parameters field of subjectPublicKeyInfo.)
	All RSA signatures must be generated and verified according to PKCS#1		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.
	EDITOR: Most of the cipher suites below have been left as ??. The		EDITOR: Most of the cipher suites below have been left as ??. The
	skipping to change at page 33, line 42 ¶		skipping to change at page 34, line 4 ¶
	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
	TBD		University of California, Berkeley
			EECS -- Computer Science Division
			513 Soda Hall
			Berkeley, CA 94720-1776
			USA
			EMail: bodo@openssl.org
	EMail: moeller@cdc.informatik.tu-darmstadt.de
	Chris Hawk		Chris Hawk
	Independent Consultant		Independent Consultant
	EMail: chris@socialeng.com		EMail: chris@socialeng.com
	Nelson Bolyard		Nelson Bolyard
	Netscape		Netscape
	EMail: misterssl@aol.com		EMail: misterssl@aol.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 23 change blocks.
	28 lines changed or deleted		37 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/