< draft-ietf-curdle-cms-ecdh-new-curves-03.txt		draft-ietf-curdle-cms-ecdh-new-curves-04.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 10 October 2017 10 April 2017		Expires: 10 October 2017 10 April 2017
	Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm		Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm
	with X25519 and X448 in the Cryptographic Message Syntax (CMS)		with X25519 and X448 in the Cryptographic Message Syntax (CMS)
	<draft-ietf-curdle-cms-ecdh-new-curves-03.txt>		<draft-ietf-curdle-cms-ecdh-new-curves-04.txt>
	Abstract		Abstract
	This document describes the conventions for using Elliptic Curve		This document describes the conventions for using Elliptic Curve
	Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and		Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and
	curve448 in the Cryptographic Message Syntax (CMS).		curve448 in the Cryptographic Message Syntax (CMS).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	generated on the same elliptic curve as the public key of the		generated on the same elliptic curve as the public key of the
	recipient. The ephemeral key pair is used for a single CMS protected		recipient. The ephemeral key pair is used for a single CMS protected
	content type, and then it is discarded. The originator obtains the		content type, and then it is discarded. The originator obtains the
	recipient's static public key from the recipient's certificate		recipient's static public key from the recipient's certificate
	[PROFILE].		[PROFILE].
	X25519 is described in Section 6.1 of [CURVES], and X448 is described		X25519 is described in Section 6.1 of [CURVES], and X448 is described
	in Section 6.2 of [CURVES]. Since curve25519 and curve448 have		in Section 6.2 of [CURVES]. Since curve25519 and curve448 have
	cofactors of 8 and 4, respectively, an input point of small order		cofactors of 8 and 4, respectively, an input point of small order
	will eliminate any contribution from the other party's private key.		will eliminate any contribution from the other party's private key.
	As described in Section 7 of [CURVES], implementations MAY detect		As described in Section 7 of [CURVES], implementations SHOULD detect
	this situation by checking for the all-zero output.		this situation by checking for the all-zero output.
	In [CURVES], the shared secret value that is produced by ECDH is		In [CURVES], the shared secret value that is produced by ECDH is
	called K. (In some other specifications, the shared secret value is		called K. (In some other specifications, the shared secret value is
	called Z.) A key derivation function (KDF) is used to produce a		called Z.) A key derivation function (KDF) is used to produce a
	pairwise key-encryption key from the shared secret value (K), the		pairwise key-encryption key from the shared secret value (K), the
	length of the key-encryption key, and the DER-encoded ECC-CMS-		length of the key-encryption key, and the DER-encoded ECC-CMS-
	SharedInfo structure [CMSECC].		SharedInfo structure [CMSECC].
	The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for		The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	additional keying material supplied by the sending agent. Note that		additional keying material supplied by the sending agent. Note that
	[CMS] requires implementations to accept a KeyAgreeRecipientInfo		[CMS] requires implementations to accept a KeyAgreeRecipientInfo
	SEQUENCE that includes the ukm field. If the ukm field is present,		SEQUENCE that includes the ukm field. If the ukm field is present,
	the ukm is placed in the entityUInfo field. The ukm value need not		the ukm is placed in the entityUInfo field. The ukm value need not
	be longer than the key-encryption key that will be produced by the		be longer than the key-encryption key that will be produced by the
	KDF. When present, the ukm ensures that a different key-encryption		KDF. When present, the ukm ensures that a different key-encryption
	key is generated, even when the originator ephemeral private key is		key is generated, even when the originator ephemeral private key is
	improperly used more than once.		improperly used more than once.
	The ECC-CMS-SharedInfo suppPubInfo field contains the length of the		The ECC-CMS-SharedInfo suppPubInfo field contains the length of the
	generated key-encryption key, in bits, represented as a 32-bit		generated key-encryption key, in bits, represented as a 32-bit number
	number. For example, the key length for AES-256 [AES] would be		in network byte order. For example, the key length for AES-256 [AES]
	0x00000100.		would be 0x00000100.
	2.1. ANSI-X9.63-KDF		2.1. ANSI-X9.63-KDF
	The ANSI-X9.63-KDF key derivation function is a simple construct		The ANSI-X9.63-KDF key derivation function is a simple construct
	based on a one-way hash function described in ANS X9.63 [X963]. This		based on a one-way hash function described in ANS X9.63 [X963]. This
	KDF is also described in Section 3.6.1 of [SEC1].		KDF is also described in Section 3.6.1 of [SEC1].
	Three values are concatenated to produce the input string to the KDF:		Three values are concatenated to produce the input string to the KDF:
	1. The shared secret value generated by ECDH, K.		1. The shared secret value generated by ECDH, K.
	2. The iteration counter, starting with one, as described below.		2. The iteration counter, starting with one, as described below.
	3. The DER-encoded ECC-CMS-SharedInfo structure.		3. The DER-encoded ECC-CMS-SharedInfo structure.
	To generate a key-encryption key (KEK), the KDF generates one or more		To generate a key-encryption key (KEK), the KDF generates one or more
	KM blocks, with the counter starting at 0x00000001, and incrementing		KM blocks, with the counter starting at 0x00000001, and incrementing
	the counter for each subsequent KM block until enough material has		the counter for each subsequent KM block until enough material has
	been generated. The 32-bit counter is represented in network byte		been generated. The 32-bit counter is represented in network byte
	order. The KM blocks are concatenated left to right to produce the		order. The KM blocks are concatenated left to right, and then the
	pairwise key-encryption key, KEK:		leftmost portion of the result is used as the pairwise key-encryption
			key, KEK:
	KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))		KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))
	KEK = KM(counter=1) || KM(counter=2) ...		KEK = KM(counter=1) || KM(counter=2) ...
	2.2. HKDF		2.2. HKDF
	The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a		The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a
	robust construct based on a one-way hash function described in RFC		robust construct based on a one-way hash function described in RFC
	5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed		5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	The fields of the KeyAgreeRecipientInfo syntax MUST be populated as		The fields of the KeyAgreeRecipientInfo syntax MUST be populated as
	described in this section when X25519 or X448 is employed for one or		described in this section when X25519 or X448 is employed for one or
	more recipients.		more recipients.
	The KeyAgreeRecipientInfo version MUST be 3.		The KeyAgreeRecipientInfo version MUST be 3.
	The KeyAgreeRecipientInfo originator provides three alternatives for		The KeyAgreeRecipientInfo originator provides three alternatives for
	identifying the originator's public key, and the originatorKey		identifying the originator's public key, and the originatorKey
	alternative MUST be used. The originatorKey MUST contain an		alternative MUST be used. The originatorKey MUST contain an
	ephemeral key for the originator. The originatorKey algorithm field		ephemeral key for the originator. The originatorKey algorithm field
	MUST contain the id-ecPublicKey object identifier along with		MUST contain the id-X25519 or the id-X448 object identifier. The
	ECParameters as specified in [PKIXECC]. The originator's ephemeral		originator's ephemeral public key MUST be encoded as an OCTET STRING.
	public key MUST be encoded using the type ECPoint as specified in
	[CMSECC]. As a convenience, the definitions are repeated here:
	id-ecPublicKey OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
	ECPoint ::= OCTET STRING
	ECParameters ::= CHOICE {
	namedCurve OBJECT IDENTIFIER
	-- implicitCurve NULL --
	-- specifiedCurve SpecifiedECDomain -- }
	The object identifiers for X25519 and X448 have been assigned in		The object identifiers for X25519 and X448 have been assigned in
	[ID.curdle-pkix]. They are repeated below for convenience.		[ID.curdle-pkix]. They are repeated below for convenience.
	When using X25519, the ECPoint contains exactly 32 octets, and the		When using X25519, the public key contains exactly 32 octets, and the
	ECParameters namedCurve MUST contain the following object identifier:		id-X25519 object identifier is used:
	id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }		id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
	When using X448, the ECPoint contains exactly 56 octets, and the		When using X448, the public key contains exactly 56 octets, and the
	ECParameters namedCurve MUST contain the following object identifier:		id-X448 object identifier is used:
	id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }		id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
	KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires		KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires
	implementations to accept a KeyAgreeRecipientInfo SEQUENCE that		implementations to accept a KeyAgreeRecipientInfo SEQUENCE that
	includes the ukm field. If present, the ukm is placed in the		includes the ukm field. If present, the ukm is placed in the
	entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The		entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The
	ukm value need not be longer than the key-encryption key produced by		ukm value need not be longer than the key-encryption key produced by
	the KDF.		the KDF.
End of changes. 8 change blocks.
	26 lines changed or deleted		15 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/