< draft-ietf-tls-rfc4492bis-10.txt		draft-ietf-tls-rfc4492bis-11.txt >
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Obsoletes: 4492 (if approved) S. Josefsson		Obsoletes: 4492 (if approved) S. Josefsson
	Intended status: Standards Track SJD AB		Intended status: Standards Track SJD AB
	Expires: July 15, 2017 M. Pegourie-Gonnard		Expires: July 15, 2017 M. Pegourie-Gonnard
	Independent / PolarSSL		Independent / PolarSSL
	January 11, 2017		January 11, 2017
	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer		Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier		Security (TLS) Versions 1.2 and Earlier
	draft-ietf-tls-rfc4492bis-10		draft-ietf-tls-rfc4492bis-11
	Abstract		Abstract
	This document describes key exchange algorithms based on Elliptic		This document describes key exchange algorithms based on Elliptic
	Curve Cryptography (ECC) for the Transport Layer Security (TLS)		Curve Cryptography (ECC) for the Transport Layer Security (TLS)
	protocol. In particular, it specifies the use of Ephemeral Elliptic		protocol. In particular, it specifies the use of Ephemeral Elliptic
	Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the		Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
	use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards		use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
	Digital Signature Algorithm (EdDSA) as authentication mechanisms.		Digital Signature Algorithm (EdDSA) as authentication mechanisms.
	skipping to change at page 24, line 25 ¶		skipping to change at page 24, line 25 ¶
	algorithm wih no hashing (EdDSA will internally run the data through		algorithm wih no hashing (EdDSA will internally run the data through
	the PH function).		the PH function).
	RFC 4492 anticipated the standardization of a mechanism for		RFC 4492 anticipated the standardization of a mechanism for
	specifying the required hash function in the certificate, perhaps in		specifying the required hash function in the certificate, perhaps in
	the parameters field of the subjectPublicKeyInfo. Such		the parameters field of the subjectPublicKeyInfo. Such
	standardization never took place, and as a result, SHA-1 is used in		standardization never took place, and as a result, SHA-1 is used in
	TLS 1.1 and earlier (except for EdDSA, which uses identity function).		TLS 1.1 and earlier (except for EdDSA, which uses identity function).
	TLS 1.2 added a SignatureAndHashAlgorithm parameter to the		TLS 1.2 added a SignatureAndHashAlgorithm parameter to the
	DigitallySigned struct, thus allowing agility in choosing the		DigitallySigned struct, thus allowing agility in choosing the
	signature hash. EdDSA signatures MUST have HashAlgorithm of 0		signature hash. EdDSA signatures MUST have HashAlgorithm of TBD5
	(None).		(Intrinsic).
	All RSA signatures must be generated and verified according to		All RSA signatures must be generated and verified according to
	[PKCS1] block type 1.		[PKCS1] block type 1.
	5.11. Public Key Validation		5.11. Public Key Validation
	With the NIST curves, each party must validate the public key sent by		With the NIST curves, each party must validate the public key sent by
	its peer. A receiving party MUST check that the x and y parameters		its peer. A receiving party MUST check that the x and y parameters
	from the peer's public value satisfy the curve equation, y^2 = x^3 +		from the peer's public value satisfy the curve equation, y^2 = x^3 +
	ax + b mod p. See section 2.3 of [Menezes] for details. Failing to		ax + b mod p. See section 2.3 of [Menezes] for details. Failing to
End of changes. 2 change blocks.
	3 lines changed or deleted		3 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/