< draft-ietf-tls-ecc-02.txt		draft-ietf-tls-ecc-03.txt >
	TLS Working Group V. Gupta		TLS Working Group V. Gupta
	Internet-Draft Sun Labs		Internet-Draft Sun Labs
	Expires: February 27, 2003 S. Blake-Wilson		Expires: December 2003 S. Blake-Wilson
	BCI		BCI
	B. Moeller		B. Moeller
	Technische Universitaet Darmstadt		Technische Universitaet Darmstadt
	C. Hawk		C. Hawk
	Independent Consultant		Independent Consultant
	August 29, 2002		June 2003
	ECC Cipher Suites for TLS		ECC Cipher Suites for TLS
	<draft-ietf-tls-ecc-02.txt>		<draft-ietf-tls-ecc-03.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 37 ¶		skipping to change at page 1, line 37 ¶
	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 February 27, 2003.		This Internet-Draft will expire on September 30, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). 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 33 ¶		skipping to change at page 2, line 33 ¶
	3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . . 10		3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Data Structures and Computations . . . . . . . . . . . . . . . 11		4. Data Structures and Computations . . . . . . . . . . . . . . . 11
	4.1 Server Certificate . . . . . . . . . . . . . . . . . . . . . . 11		4.1 Server Certificate . . . . . . . . . . . . . . . . . . . . . . 11
	4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 12		4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 12
	4.3 Certificate Request . . . . . . . . . . . . . . . . . . . . . 17		4.3 Certificate Request . . . . . . . . . . . . . . . . . . . . . 17
	4.4 Client Certificate . . . . . . . . . . . . . . . . . . . . . . 18		4.4 Client Certificate . . . . . . . . . . . . . . . . . . . . . . 18
	4.5 Client Key Exchange . . . . . . . . . . . . . . . . . . . . . 19		4.5 Client Key Exchange . . . . . . . . . . . . . . . . . . . . . 19
	4.6 Certificate Verify . . . . . . . . . . . . . . . . . . . . . . 20		4.6 Certificate Verify . . . . . . . . . . . . . . . . . . . . . . 20
	4.7 Elliptic Curve Certificates . . . . . . . . . . . . . . . . . 22		4.7 Elliptic Curve Certificates . . . . . . . . . . . . . . . . . 22
	4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22		4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22
	5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24		5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 23
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 26		6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 27		7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 26
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
	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 [2], which gives approximate comparable		the following table, based on [2], which gives approximate comparable
	key sizes for symmetric- and asymmetric-key cryptosystems based on		key sizes for symmetric- and asymmetric-key cryptosystems based on
	the best-known algorithms for attacking them.		the best-known algorithms for attacking them.
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	for an ECC-based handshake, their encoding in TLS messages and the		for an ECC-based handshake, their encoding in TLS messages and the
	processing of those messages. Section 5 defines new ECC-based cipher		processing of those messages. Section 5 defines new ECC-based cipher
	suites and identifies a small subset of these as recommended for all		suites and identifies a small subset of these as recommended for all
	implementations of this specification. Section 6, Section 7 and		implementations of this specification. Section 6, Section 7 and
	Section 8 mention security considerations, intellectual property		Section 8 mention security considerations, intellectual property
	rights, and acknowledgments, respectively. This is followed by a		rights, and acknowledgments, respectively. This is followed by a
	list of references cited in this document and the authors' contact		list of references cited in this document and the authors' contact
	information.		information.
	Implementation of this specification requires familiarity with both		Implementation of this specification requires familiarity with both
	TLS [3] and ECC [5][6][7][8] .		TLS [3] and ECC [5][6][7][9] .
	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
	skipping to change at page 17, line 7 ¶		skipping to change at page 17, line 7 ¶
	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[20];		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 [3]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA		TLS [3]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA
	signatures are generated and verified as described in Section 4.8.		signatures are generated and verified as described in Section 4.8.
			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
			same length as the curve order n using the conversion routine
			specified in Section 4.3.1 of [7]. The two byte strings are
			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
	ECDH public key corresponding to these parameters according to the		ECDH public key corresponding to these parameters according to the
	ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to		ECKAS-DH1 scheme from IEEE 1363 [6]. 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:
	skipping to change at page 17, line 46 ¶		skipping to change at page 18, line 6 ¶
	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(5), rsa_fixed_ecdh(6),		ecdsa_sign(?), rsa_fixed_ecdh(?),
	ecdsa_fixed_ecdh(7), (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.
	NOTE: SSL 3.0 [4] assigns values 5 and 6 differently		EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
	(rsa_ephemeral_dh and dss_ephemeral_dh); these		ecdsa_fixed_ecdh have been left as ?. These values will be
	ClientCertificateType values are not used by TLS.		assigned when this draft progresses to RFC. Earlier versions of
			this draft used the values 5, 6, and 7 - however these values have
			been removed since they are used differently by SSL 3.0 and 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
	skipping to change at page 21, line 24 ¶		skipping to change at page 21, line 24 ¶
	Structure of this message:		Structure of this message:
	The TLS CertificateVerify message is extended as follows.		The TLS CertificateVerify message is extended as follows.
	enum { ecdsa } SignatureAlgorithm;		enum { ecdsa } SignatureAlgorithm;
	select (SignatureAlgorithm) {		select (SignatureAlgorithm) {
	case ecdsa:		case ecdsa:
	digitally-signed struct {		digitally-signed struct {
	opaque sha_hash[20];		opaque sha_hash[sha_size];
	};		};
	} Signature;		} Signature;
	For the ecdsa case, the signature field in the CertificateVerify		For the ecdsa case, the signature field in the CertificateVerify
	message contains an ECDSA signature computed over handshake messages		message contains an ECDSA signature computed over handshake messages
	exchanged so far. ECDSA signatures are computed as described in		exchanged so far. ECDSA signatures are computed as described in
	Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a		Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a
	pair of integers r and s. These integers are both converted into		pair of integers r and s. These integers are both converted into
	byte strings of the same length as the curve order n using the		byte strings of the same length as the curve order n using the
	conversion routine specified in Section 4.3.1 of [7]. The two byte		conversion routine specified in Section 4.3.1 of [7]. The two byte
	skipping to change at page 22, line 16 ¶		skipping to change at page 22, line 16 ¶
	X509 certificates containing ECC public keys or signed using ECDSA		X509 certificates containing ECC public keys or signed using ECDSA
	MUST comply with [14]. Clients SHOULD use the elliptic curve domain		MUST comply with [14]. Clients SHOULD use the elliptic curve domain
	parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2		parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2
	[12].		[12].
	4.8 ECDH, ECDSA and RSA Computations		4.8 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 [6]		as the shared secret calculation) MUST be performed according to [6]
	using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation		using
	primitive, and the KDF1 key derivation function using SHA-1 [9]. The
	output of this scheme, i.e. the 20-byte SHA-1 output from the KDF,
	is the premaster secret.
	DISCUSSION POINT:
	Using KDF1 with SHA-1 limits the security to at most 160 bits,
	independently of the elliptic curve used for ECDH. An alternative
	way to define the protocol would be to employ the identity map as key
	derivation function (in other words, omit the SHA-1 step and directly
	use the octet string representation of the x coordinate of the
	elliptic curve point resulting from the ECDH computation as premaster
	secret). This is similar to conventional DH in TLS [3], and it is
	appropriate for TLS given that TLS already defines a PRF for
	determining the actual symmetric keys.
	The TLS PRF (which is used to derive the master secret from the
	premaster secret and the symmetric keys from the master secret) has
	an internal security limit of at most 288 bits (128 + 160 for MD5 and
	SHA-1), so the use of KDF1 with SHA-1 can be seen to actually weaken
	the theoretical security of the protocol.
	Options to solve this problem include the following:
	o Omit the SHA-1 step as describe above. (BM)
	o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits
	(more precisely: for curves where FE2OSP returns an octet string
	up to 36 octets) and omit the SHA-1 step only for larger curves.
	(SBW/BM)
	o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits
	and use KDF1 with SHA-256 or SHA-384 or SHA-512 for larger curves.
	(SBW)
	The first solution will break compatibility with existing		o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation
	implementations based on draft-ietf-tls-ecc-01.txt. The second and		primitive, the KDF1 key derivation function using SHA-1 [8], and
	third solutions are somewhat of a kludge, but maintain compatibility		null key derivation parameters "P" for elliptic curve parameters
	(in a large range).		where field elements are represented as octet strings of length 24
			or less (using the IEEE 1363 FE2OSP); in this case, the premaster
			secret is the output of the ECKAS-DH1 scheme, i.e. the 20-byte
			SHA-1 output from the KDF.
	OPEN QUESTION: We invite comments on which of these solutions would		o the ECKAS-DH1 scheme with the identity map as key derivation
	be preferred.		function for elliptic curve parameters where field elements are
			represented as octet strings of length more than 24; in this case,
			the premaster secret is the x-coordinate of the ECDH shared secret
			elliptic curve point, i.e. the octet string Z in IEEE 1363
			terminology.
	END OF DISCUSSION POINT.		Note that a new extension may be introduced in the future to allow
			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
			process detailed above. This may be desirable, for example, to
			support compatibility with the planned NIST key agreement standard.
	All ECDSA computations MUST be performed according to ANSI X9.62 [7]		All ECDSA computations MUST be performed according to ANSI X9.62 [7]
	using the SHA-1 [9] hash function. The 20 bytes of the SHA-1 are run		or its successors. Data to be signed/verified is hashed and the
	directly through the ECDSA algorithm with no additional hashing.		result run directly through the ECDSA algorithm with no additional
			hashing. The default hash function is SHA-1 [8] and sha_size (see
			Section 4.2 and Section 4.6) is 20. However, an alternative hash
			function, such as one of the new SHA hash functions specified in FIPS
			180-2 [8], may be used instead if the certificate containing the EC
			public key explicitly requires use of another hash function.
	All RSA signatures must be generated and verified according to PKCS#1		All RSA signatures must be generated and verified according to PKCS#1
	[10].		[10].
	5. Cipher Suites		5. 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
			values 47-4C correspond to cipher suites which are known to have been
			implemented and are therefore proposed here. The final determination
			of cipher suite numbers will occur when this draft progresses to RFC.
			Implementers using the values 47-4C should therefore be wary that
			these values may change.
	CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }		CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }
	CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }		CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }
	CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }		CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }
	CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }		CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }
	CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B }		CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B }
	CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C }		CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C }
	CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
	CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }		CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
	skipping to change at page 26, line 7 ¶		skipping to change at page 25, line 7 ¶
	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.
	6. Security Considerations		6. Security Considerations
	This document is entirely concerned with security mechanisms.
	This document is based on [3], [6], [7] and [11]. The appropriate		This document is based on [3], [6], [7] and [11]. The appropriate
	security considerations of those documents apply.		security considerations of those documents apply.
			For ECDH (Section 4.8), this document specifies two different ways to
			compute the premaster secret. The choice of the method is determined
			by the elliptic curve. Earlier versions of this specification used
			the KDF1 key derivation function with SHA-1 in all cases; the current
			version keeps this key derivation function only for curves where
			field elements are represented as octet strings of length 24 or less
			(i.e. up to 192 bits), but omits it for larger curves.
			Rationale: Using KDF1 with SHA-1 limits the security to at most 160
			bits, independently of the elliptic curve used for ECDH. For large
			curves, this would result in worse security than expected. Using a
			specific key derivation function for ECDH is not really necessary as
			TLS always uses its PRF to derive the master secret from the
			premaster secret. For large curves, the current specification
			handles ECDH like the basic TLS specification [11] handles standard
			DH. For smaller curves where the extra KDF1 step does not weaken
			security, the current specification keeps the KDF1 step to obtain
			compatibility with existing implementations of earlier versions of
			this specification. Note that the threshold for switching between
			the two ECDH calculation methods is necessarily somewhat arbitrary;
			192-bit ECC corresponds to approximately 96 bits of security in the
			light of square root attacks, so the 160 bits provided by SHA-1 are
			comfortable at this limit.
	7. Intellectual Property Rights		7. Intellectual Property Rights
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to the specification contained in this document. For more		regard to the specification contained in this document. For more
	information, consult the online list of claimed rights (http://		information, consult the online list of claimed rights (http://
	www.ietf.org/ipr.html).		www.ietf.org/ipr.html).
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	skipping to change at page 29, line 31 ¶		skipping to change at page 28, line 31 ¶
	[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://		[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://
	www.secg.org/>.		www.secg.org/>.
	[6] IEEE, "Standard Specifications for Public Key Cryptography",		[6] IEEE, "Standard Specifications for Public Key Cryptography",
	IEEE 1363, 2000.		IEEE 1363, 2000.
	[7] ANSI, "Public Key Cryptography For The Financial Services		[7] 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.
	[8] NIST, "Digital Signature Standard", FIPS 180-1, 2000.		[8] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
	[9] NIST, "Secure Hash Standard", FIPS 186-2, 1995.		[9] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
	[10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version		[10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
	1.5", PKCS 1, November 1993.		1.5", PKCS 1, November 1993.
	[11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for		[11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
	Transport Layer Security (TLS)", RFC 3268, June 2002.		Transport Layer Security (TLS)", RFC 3268, June 2002.
	[12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,		[12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
	2000, <http://www.secg.org/>.		2000, <http://www.secg.org/>.
	skipping to change at page 31, line 7 ¶		skipping to change at page 30, line 7 ¶
	Phone: +49 6151 16 6628		Phone: +49 6151 16 6628
	EMail: moeller@cdc.informatik.tu-darmstadt.de		EMail: moeller@cdc.informatik.tu-darmstadt.de
	Chris Hawk		Chris Hawk
	Independent Consultant		Independent Consultant
	EMail: chris@socialeng.com		EMail: chris@socialeng.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). 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.
	69 lines changed or deleted		88 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/