< draft-ietf-curdle-cms-ecdh-new-curves-05.txt		draft-ietf-curdle-cms-ecdh-new-curves-06.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 6 November 2017 6 May 2017		Expires: 10 November 2017 10 May 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-05.txt>		<draft-ietf-curdle-cms-ecdh-new-curves-06.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 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on 6 November 2017.		This Internet-Draft will expire on 10 November 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	In 1976, Diffie and Hellman described a means for two parties to		In 1976, Diffie and Hellman described a means for two parties to
	agree upon a shared secret value in manner that prevents		agree upon a shared secret value in manner that prevents
	eavesdroppers from learning the shared secret value [DH1976]. This		eavesdroppers from learning the shared secret value [DH1976]. This
	secret may then be converted into pairwise symmetric keying material		secret may then be converted into pairwise symmetric keying material
	for use with other cryptographic algorithms. Over the years, many		for use with other cryptographic algorithms. Over the years, many
	variants of this fundamental technique have been developed. This		variants of this fundamental technique have been developed. This
	document describes the conventions for using Ephemeral-Static		document describes the conventions for using Ephemeral-Static
	Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and		Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and
	X448 [CURVES].		X448 [CURVES].
	The originator uses an ephemeral public/private key pair that is		The originator MUST use an ephemeral public/private key pair that is
	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 MUST be used for a single CMS
	content type, and then it is discarded. The originator obtains the		protected content type, and then it MUST be discarded. The
	recipient's static public key from the recipient's certificate		originator obtains the recipient's static public key from the
	[PROFILE].		recipient's certificate [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]. As described in Section 7 of [CURVES],
	cofactors of 8 and 4, respectively, an input point of small order		curve25519 and curve448 have cofactors of 8 and 4, respectively, and
	will eliminate any contribution from the other party's private key.		so an input point of small order will eliminate any contribution from
	As described in Section 7 of [CURVES], implementations SHOULD detect		the other party's private key. Conforming implementations MUST check
	this situation by checking for the all-zero output.		for the all-zero output to prevent this situation.
	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 (KEK) from the shared secret value (K),		pairwise key-encryption key (KEK) from the shared secret value (K),
	the length of the key-encryption key, and the DER-encoded ECC-CMS-		the 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
	convenience.		convenience.
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	The ECC-CMS-SharedInfo keyInfo field contains the object identifier		The ECC-CMS-SharedInfo keyInfo field contains the object identifier
	of the key-encryption algorithm and associated parameters. This		of the key-encryption algorithm and associated parameters. This
	algorithm will be used to wrap the content-encryption key. For		algorithm will be used to wrap the content-encryption key. For
	example, the AES Key Wrap algorithm [AESKW] does not need parameters,		example, the AES Key Wrap algorithm [AESKW] does not need parameters,
	so the algorithm identifier parameters are absent.		so the algorithm identifier parameters are absent.
	The ECC-CMS-SharedInfo entityUInfo field optionally contains		The ECC-CMS-SharedInfo entityUInfo field optionally contains
	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. There is no security		the ukm is placed in the entityUInfo field. By including the ukm, a
	benefit to using a ukm value that is longer than the key-encryption		different key-encryption key is generated even when the originator
	key that will be produced by the KDF. When present, the ukm ensures		ephemeral private key is improperly used more than once. Therefore,
	that a different key-encryption key is generated, even when the		if the ukm field is present, it MUST be selected in a manner that
	originator ephemeral private key is improperly used more than once.		provides with very high probability a unique value; however, there is
			no security benefit to using a ukm value that is longer than the key-
			encryption key that will be produced by the KDF.
	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 number		generated key-encryption key, in bits, represented as a 32-bit number
	in network byte order. For example, the key length for AES-256 [AES]		in network byte order. For example, the key length for AES-256 [AES]
	would be 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
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 34 ¶
	constructing an enveloped-data content type in Section 6 of [CMS].		constructing an enveloped-data content type in Section 6 of [CMS].
	A content-encryption key MUST be randomly generated for each instance		A content-encryption key MUST be randomly generated for each instance
	of an enveloped-data content type. The content-encryption key is		of an enveloped-data content type. The content-encryption key is
	used to encrypt the content.		used to encrypt the content.
	3.1. EnvelopedData Fields		3.1. EnvelopedData Fields
	The enveloped-data content type is ASN.1 encoded using the		The enveloped-data content type is ASN.1 encoded using the
	EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be		EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be
	populated as described in [CMS]; for the recipients that use X25519		populated as described in Section 6 of [CMS]. The RecipientInfo
	or X448 the RecipientInfo kari choice MUST be used.		choice is described in Section 6.2 of [CMS], and repeated here for
			convenience.
			RecipientInfo ::= CHOICE {
			ktri KeyTransRecipientInfo,
			kari [1] KeyAgreeRecipientInfo,
			kekri [2] KEKRecipientInfo,
			pwri [3] PasswordRecipientinfo,
			ori [4] OtherRecipientInfo }
			For the recipients that use X25519 or X448 the RecipientInfo kari
			choice MUST be used.
	3.2. KeyAgreeRecipientInfo Fields		3.2. KeyAgreeRecipientInfo Fields
	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
End of changes. 8 change blocks.
	20 lines changed or deleted		33 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/