< draft-ietf-curdle-cms-ecdh-new-curves-00.txt		draft-ietf-curdle-cms-ecdh-new-curves-01.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 5 November 2016 5 May 2016		Expires: 8 March 2017 8 September 2016
	Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with		Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm
	curve25519 and curve448 in the Cryptographic Message Syntax (CMS)		with X25519 and X448 in the Cryptographic Message Syntax (CMS)
	<draft-ietf-curdle-cms-ecdh-new-curves-00.txt>		<draft-ietf-curdle-cms-ecdh-new-curves-01.txt>
	Abstract		Abstract
	This document describes the conventions for using Elliptic Curve		This document describes the conventions for using Elliptic Curve
	Diffie-Hellamn (ECDH) key agreement algorithm using curve25519 and		Diffie-Hellamn (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 5 November 2016.		This Internet-Draft will expire on 8 March 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 20 ¶		skipping to change at page 2, line 20 ¶
	agreement is supported in three CMS content types: the enveloped-data		agreement is supported in three CMS content types: the enveloped-data
	content type [CMS], authenticated-data content type [CMS], and the		content type [CMS], authenticated-data content type [CMS], and the
	authenticated-enveloped-data content type [AUTHENV].		authenticated-enveloped-data content type [AUTHENV].
	The conventions for using some Elliptic Curve Cryptography (ECC)		The conventions for using some Elliptic Curve Cryptography (ECC)
	algorithms in CMS are described in [CMSECC]. These conventions cover		algorithms in CMS are described in [CMSECC]. These conventions cover
	the use of ECDH with some curves other than curve25519 and curve448		the use of ECDH with some curves other than curve25519 and curve448
	[CURVE]. Those other curves are not deprecated, but support for		[CURVE]. Those other curves are not deprecated, but support for
	curve25519 and curve448 is encouraged.		curve25519 and curve448 is encouraged.
			When these two curves are used with with Diffie-Hellman key
			agreement, they are referred to as X25519 and X448.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [STDWORDS].		document are to be interpreted as described in RFC 2119 [STDWORDS].
	1.2. ASN.1		1.2. ASN.1
	CMS values are generated using ASN.1 [X680], which uses the Basic		CMS values are generated using ASN.1 [X680], which uses the Basic
	Encoding Rules (BER) and the Distinguished Encoding Rules (DER)		Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 44 ¶
	2. Key Agreement		2. Key Agreement
	In 1976, Diffie and Hellman describe a means for two parties to agree		In 1976, Diffie and Hellman describe a means for two parties to agree
	upon a shared secret value in manner that prevents eavesdroppers from		upon a shared secret value in manner that prevents eavesdroppers from
	learning the shared secret value [DH1976]. This secret may then be		learning the shared secret value [DH1976]. This secret may then be
	converted into pairwise symmetric keying material for use with other		converted into pairwise symmetric keying material for use with other
	cryptographic algorithms. Over the years, many variants of this		cryptographic algorithms. Over the years, many variants of this
	fundamental technique have been developed. This document describes		fundamental technique have been developed. This document describes
	the conventions for using Ephemeral-Static Elliptic Curve Diffie-		the conventions for using Ephemeral-Static Elliptic Curve Diffie-
	Hellamn (ECDH) key agreement using curve25519 and curve448.		Hellamn (ECDH) key agreement using X25519 and X448 [CURVE].
	The originator uses an ephemeral public/private key pair that is		The originator uses 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 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].
	ECDH with curve25519 is described in Section 6.1 of [CURVE], and ECDH		X25519 is described in Section 6.1 of [CURVE], and X448 is described
	with curve448 is described in Section 6.2 of [CURVE]. Since		in Section 6.2 of [CURVE]. Since curve25519 and curve448 have
	curve25519 and curve448 have cofactors of 8 and 4, respectively, an		cofactors of 8 and 4, respectively, an input point of small order
	input point of small order will eliminate any contribution from the		will eliminate any contribution from the other party's private key.
	other party's private key. As described in Section 7 of [CURVE],		As described in Section 7 of [CURVE], implementations MAY detect this
	implementations MAY detect this situation by checking for the all-		situation by checking for the all-zero output.
	zero output.
	In [CURVE], the shared secret value that is produced by ECDH is		In [CURVE], 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 K, the length of the key-encryption		pairwise key-encryption key from K, the length of the key-encryption
	key, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC].		key, and the DER-encoded ECC-CMS-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 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	recipient. Then, the key-encryption key is used to wrap the content-		recipient. Then, the key-encryption key is used to wrap the content-
	encryption key for that recipient. When there more than one		encryption key for that recipient. When there more than one
	recipient, the same content-encryption key is wrapped for each of		recipient, the same content-encryption key is wrapped for each of
	them.		them.
	A compliant implementation MUST meet the requirements for		A compliant implementation MUST meet the requirements for
	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 encipher 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 ECDH		populated as described in [CMS]; for the recipients that use X25519
	with curve25519 or curve448 the RecipientInfo kari choice MUST be		or X448 the RecipientInfo kari choice MUST be used.
	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 ECDH with curve25519 or curve448 is		described in this section when X25519 or X448 is employed for one or
	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-ecPublicKey object identifier along with
	ECParameters as specified in [PKIXECC]. The originator's ephemeral		ECParameters as specified in [PKIXECC]. The originator's ephemeral
	public key MUST be encoded using the type ECPoint as specified in		public key MUST be encoded using the type ECPoint as specified in
			[CMSECC]. As a convenience, the definitions are repeated here:
	[CMSECC]. As a courtesy, the definitions are repeated here:
	id-ecPublicKey OBJECT IDENTIFIER ::= {		id-ecPublicKey OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }		iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
	ECPoint ::= OCTET STRING		ECPoint ::= OCTET STRING
	ECParameters ::= CHOICE {		ECParameters ::= CHOICE {
	namedCurve OBJECT IDENTIFIER		namedCurve OBJECT IDENTIFIER
	-- implicitCurve NULL		-- implicitCurve NULL
	-- specifiedCurve SpecifiedECDomain -- }		-- specifiedCurve SpecifiedECDomain -- }
	The object identifiers for curve25519 and curve448 have been assigned		The object identifiers for X25519 and X448 have been assigned in
	in [ID.josefsson-pkix-newcurves]. They are repeated below for		[ID.curdle-pkix]. They are repeated below for convenience.
	convenience.
	When using curve25519, the ECPoint contains exactly 32 octets, and		When using X25519, the ECPoint contains exactly 32 octets, and the
	the ECParameters namedCurve MUST contain the following object		ECParameters namedCurve MUST contain the following object identifier:
	identifier:
	id-Curve25519 OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11591 15 1 }		id-X25519 OBJECT IDENTIFIER ::= { 1.3.101.110 }
	When using curve448, the ECPoint contains exactly 56 octets, and the		When using X448, the ECPoint contains exactly 56 octets, and the
	ECParameters namedCurve MUST contain the following object identifier:		ECParameters namedCurve MUST contain the following object identifier:
	id-Curve448 OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11591 15 2 }		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.
	KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object		KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object
	identifier of the key-encryption algorithm that will be used to wrap		identifier of the key-encryption algorithm that will be used to wrap
	the content-encryption key. The conventions for using AES-128,		the content-encryption key. The conventions for using AES-128,
	AES-192, and AES-256 in the key wrap mode are specified in [CMSAES].		AES-192, and AES-256 in the key wrap mode are specified in [CMSAES].
	KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient		KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient
	identifier and encrypted key for one or more recipients. The		identifier and encrypted key for one or more recipients. The
	RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either		RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either
	the issuerAndSerialNumber identifying the recipient's certificate or		the issuerAndSerialNumber identifying the recipient's certificate or
	the RecipientKeyIdentifier containing the subject key identifier from		the RecipientKeyIdentifier containing the subject key identifier from
	the recipient's certificate. In both cases, the recipient's		the recipient's certificate. In both cases, the recipient's
	certificate contains the recipient's static ECDH public key with		certificate contains the recipient's static X25519 or X448 public
	curve25519 or curve448 public key. RecipientEncryptedKey		key. RecipientEncryptedKey EncryptedKey MUST contain the content-
	EncryptedKey MUST contain the content-encryption key encrypted with		encryption key encrypted with the pairwise key-encryption key using
	the pairwise key-encryption key using the algorithm specified by the		the algorithm specified by the KeyWrapAlgorithm.
	KeyWrapAlgorithm.
	4. Authenticated-data Conventions		4. Authenticated-data Conventions
	The CMS authenticated-data content type [CMS] consists an		The CMS authenticated-data content type [CMS] consists an
	authenticated content, a message authentication code (MAC), and		authenticated content, a message authentication code (MAC), and
	encrypted authentication keys for one or more recipients. The ECDH		encrypted authentication keys for one or more recipients. The ECDH
	key agreement algorithm is used to generate a pairwise key-encryption		key agreement algorithm is used to generate a pairwise key-encryption
	key between the originator and a particular recipient. Then, the		key between the originator and a particular recipient. Then, the
	key-encryption key is used to wrap the authentication key for that		key-encryption key is used to wrap the authentication key for that
	recipient. When there more than one recipient, the same		recipient. When there more than one recipient, the same
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 21 ¶
	A authentication key MUST be randomly generated for each instance of		A authentication key MUST be randomly generated for each instance of
	an authenticated-data content type. The authentication key is used		an authenticated-data content type. The authentication key is used
	to compute the MAC over the content.		to compute the MAC over the content.
	4.1. AuthenticatedData Fields		4.1. AuthenticatedData Fields
	The authenticated-data content type is ASN.1 encoded using the		The authenticated-data content type is ASN.1 encoded using the
	AuthenticatedData syntax. The fields of the AuthenticatedData syntax		AuthenticatedData syntax. The fields of the AuthenticatedData syntax
	MUST be populated as described in [CMS]; for the recipients that use		MUST be populated as described in [CMS]; for the recipients that use
	ECDH with curve25519 or curve448 the RecipientInfo kari choice MUST		X25519 or X448 the RecipientInfo kari choice MUST be used.
	be used.
	4.2. KeyAgreeRecipientInfo Fields		4.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 Section 3.2 of this document.		described in Section 3.2 of this document.
	5. Authenticated-Enveloped-data Conventions		5. Authenticated-Enveloped-data Conventions
	The CMS authenticated-enveloped-data content type content type		The CMS authenticated-enveloped-data content type content type
	[AUTHENV] consists of an authenticated and encrypted content and		[AUTHENV] consists of an authenticated and encrypted content and
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 6 ¶
	A content-authenticated-encryption key MUST be randomly generated for		A content-authenticated-encryption key MUST be randomly generated for
	each instance of an authenticated-enveloped-data content type. The		each instance of an authenticated-enveloped-data content type. The
	content-authenticated-encryption key key is used to authenticate and		content-authenticated-encryption key key is used to authenticate and
	encrypt the content.		encrypt the content.
	5.1. AuthEnvelopedData Fields		5.1. AuthEnvelopedData Fields
	The authenticated-enveloped-data content type is ASN.1 encoded using		The authenticated-enveloped-data content type is ASN.1 encoded using
	the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData		the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData
	syntax MUST be populated as described in [AUTHENV]; for the		syntax MUST be populated as described in [AUTHENV]; for the
	recipients that use ECDH with curve25519 or curve448 the		recipients that use X25519 or X448 the RecipientInfo kari choice MUST
	RecipientInfo kari choice MUST be used.		be used.
	5.2. KeyAgreeRecipientInfo Fields		5.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 Section 3.2 of this document.		described in Section 3.2 of this document.
	6. Certificate Conventions		6. Certificate Conventions
	RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates		RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates
	in Internet applications. A recipient static public key is needed		in Internet applications. A recipient static public key is needed
	for ECDH with curve25519 or curve448, and the originator obtains that		for X25519 or X448, and the originator obtains that public key from
	public key from the recipient's certificate. The conventions in this		the recipient's certificate. The conventions in this section augment
	section augment RFC 5280.		RFC 5280 [PROFILE].
	The id-ecPublicKey object identifier continues to identify the static		The id-ecPublicKey object identifier continues to identify the static
	ECDH public key for the recipient. The associated EcpkParameters		ECDH public key for the recipient. The associated EcpkParameters
	parameters structure is specified in [PKIXALG], and the namedCurve		parameters structure is specified in [PKIXALG], and the namedCurve
	alternative MUST be used. The object identifiers from Section 3.2 of		alternative MUST be used. The object identifiers from Section 3.2 of
	this document are used for curve25519 and curve448. The		this document are used for X25519 and X448. The EcpkParameters
	EcpkParameters parameters structure is repeated here for convenience:		parameters structure is repeated here for convenience:
	EcpkParameters ::= CHOICE {		EcpkParameters ::= CHOICE {
	ecParameters ECParameters,		ecParameters ECParameters,
	namedCurve OBJECT IDENTIFIER,		namedCurve OBJECT IDENTIFIER,
	implicitlyCA NULL }		implicitlyCA NULL }
	The certificate issuer MAY use indicate the intended usage for the		The certificate issuer MAY use indicate the intended usage for the
	certified public key by including the key usage certificate extension		certified public key by including the key usage certificate extension
	as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage		as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage
	extension is present in a certificate that conveys an ECDH static		extension is present in a certificate that conveys an ECDH static
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 6 ¶
	bit.		bit.
	7. Key Agreement Algorithm Identifiers		7. Key Agreement Algorithm Identifiers
	The following object identifiers are assigned to indicate ECDH with		The following object identifiers are assigned to indicate ECDH with
	HKDF using various one-way hash functions. These are expected to be		HKDF using various one-way hash functions. These are expected to be
	used as AlgorithmIdentifiers with a parameter that specifies the key-		used as AlgorithmIdentifiers with a parameter that specifies the key-
	encryption algorithm.		encryption algorithm.
	dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
	TBD 0 }		TBD0 }
	dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
	TBD 1 }		TBD1 }
	dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
	TBD 2 }		TBD2 }
	8. SMIMECapabilities Attribute Conventions		8. SMIMECapabilities Attribute Conventions
	A sending agent MAY announce to other agents that it supports ECDH		A sending agent MAY announce to other agents that it supports ECDH
	key agreement using the SMIMECapabilities signed attribute in a		key agreement using the SMIMECapabilities signed attribute in a
	signed message [SMIME] or a certificate [CERTCAP]. Following the		signed message [SMIME] or a certificate [CERTCAP]. Following the
	pattern established in [CMSECC], the SMIMECapabilities associated		pattern established in [CMSECC], the SMIMECapabilities associated
	with ECDH carries a DER-encoded object identifier that identifies		with ECDH carries a DER-encoded object identifier that identifies
	support for ECDH in conjunction with a particular KDF, and it		support for ECDH in conjunction with a particular KDF, and it
	includes a parameter that names the key wrap algorithm.		includes a parameter that names the key wrap algorithm.
	The following SMIMECapabilities values (in hexidecimal) from [CMSECC]		The following SMIMECapabilities values (in hexidecimal) from [CMSECC]
	might be of interest to implementations that support curve25519 and		might be of interest to implementations that support X25519 and X448:
	curve448:
	ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap:		ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap:
	30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04		30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04
	01 05		01 05
	ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap:		ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap:
	30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04		30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04
	01 05		01 05
	ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap:		ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap:
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 7 ¶
	ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap:		ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap:
	30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04		30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04
	01 2D		01 2D
	ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap:		ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap:
	30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04		30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04
	01 2D		01 2D
	The following SMIMECapabilities values (in hexidecimal) based on the		The following SMIMECapabilities values (in hexidecimal) based on the
	algorithm identifiers in Section 7 of this document might be of		algorithm identifiers in Section 7 of this document might be of
	interest to implementations that support curve25519 and curve448:		interest to implementations that support X25519 and X448:
	ECDH with HKDF using SHA-256; uses AES-128 key wrap:		ECDH with HKDF using SHA-256; uses AES-128 key wrap:
	TBD		TBD
	ECDH with HKDF using SHA-384; uses AES-128 key wrap:		ECDH with HKDF using SHA-384; uses AES-128 key wrap:
	TBD		TBD
	ECDH with HKDF using SHA-512; uses AES-128 key wrap:		ECDH with HKDF using SHA-512; uses AES-128 key wrap:
	TBD		TBD
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 29 ¶
	TBD		TBD
	ECDH with HKDF using SHA-384; uses AES-256 key wrap:		ECDH with HKDF using SHA-384; uses AES-256 key wrap:
	TBD		TBD
	ECDH with HKDF using SHA-512; uses AES-256 key wrap:		ECDH with HKDF using SHA-512; uses AES-256 key wrap:
	TBD		TBD
	9. Security Considerations		9. Security Considerations
	Please consult the security considerations of [CMS] and [AUTHENV] for		Please consult the security considerations of [CMS] for security
	security considerations related to the enveloped-data content type		considerations related to the enveloped-data content type and the
	and the authenticated-enveloped-data content type, respectively.		authenticated-data content type.
			Please consult the security considerations of [AUTHENV] for security
			considerations related to the authenticated-enveloped-data content
			type.
	Please consult the security considerations of [CURVES] for security		Please consult the security considerations of [CURVES] for security
	considerations related to the use of ECDH with curve25519 and		considerations related to the use of X25519 and X448.
	curve448.
	The originator uses an ephemeral public/private key pair that is		The originator uses 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 is used for a single CMS protected
	content type, and then it is discarded. If the originator wants to		content type, and then it is discarded. If the originator wants to
	be able to decrypt the content (for enveloped-data and authenticated-		be able to decrypt the content (for enveloped-data and authenticated-
	enveloped-data) or check the authentication (for authenticated-data),		enveloped-data) or check the authentication (for authenticated-data),
	then the originator needs to treat themselves as a recipient.		then the originator needs to treat themselves as a recipient.
	As specified in [CMS], implementations MUST support processing of the		As specified in [CMS], implementations MUST support processing of the
	KeyAgreeRecipientInfo ukm field, so interoperability is not a concern		KeyAgreeRecipientInfo ukm field, so interoperability is not a concern
	if the ukm is present or absent. The ukm is placed in the		if the ukm is present or absent. The ukm is placed in the
	entityUInfo field of the ECC-CMS-SharedInfo structure. When present,		entityUInfo field of the ECC-CMS-SharedInfo structure. When present,
	the ukm ensures that a different key-encryption key is generated,		the ukm ensures that a different key-encryption key is generated,
	even when the originator ephemeral private key is improperly used		even when the originator ephemeral private key is improperly used
	more than once.		more than once.
	10. IANA Considerations		10. IANA Considerations
	No IANA registrations are requested in this document.		Three object identifiers for the Key Agreement Algorithm Identifiers
			in Sections 7 are needed. Are they going to come from an IANA
			registry or from the registry that assigned the object identifiers in
			[ID.curdle-pkix]?
	11. Normative References		11. Normative References
	[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)		[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)
	Authenticated-Enveloped-Data Content Type", RFC 5083,		Authenticated-Enveloped-Data Content Type", RFC 5083,
	November 2007.		November 2007.
	[CERTCAP] Santesson, S., "X.509 Certificate Extension for		[CERTCAP] Santesson, S., "X.509 Certificate Extension for
	Secure/Multipurpose Internet Mail Extensions (S/MIME)		Secure/Multipurpose Internet Mail Extensions (S/MIME)
	Capabilities", RFC 4262, December 2005.		Capabilities", RFC 4262, December 2005.
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 34 ¶
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
	5652, September 2009.		5652, September 2009.
	[CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, January 2016.		for Security", RFC 7748, January 2016.
	[HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and-		[HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and-
	Expand Key Derivation Function (HKDF)", RFC 5869, May		Expand Key Derivation Function (HKDF)", RFC 5869, May
	2010.		2010.
	[ID.josefsson-pkix-newcurves]		[ID.curdle-pkix]
	Josefsson, S., "Using Curve25519 and Curve448 in PKIX",		Josefsson, S., and J. Schaad, "Algorithm Identifiers for
	12 October 2015, Work-in-progress.		Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for
			use in the Internet X.509 Public Key Infrastructure",
			15 August 2016, Work-in-progress.
	[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and		[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
	Identifiers for the Internet X.509 Public Key		Identifiers for the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 3279, April 2002.		(CRL) Profile", RFC 3279, April 2002.
	[PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
	"Elliptic Curve Cryptography Subject Public Key		"Elliptic Curve Cryptography Subject Public Key
	Information", RFC 5480, March 2009.		Information", RFC 5480, March 2009.
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 23 ¶
	[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[X680] ITU-T, "Information technology -- Abstract Syntax Notation		[X680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, 2002.		Recommendation X.680, 2015.
	[X690] ITU-T, "Information technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2002.		(DER)", ITU-T Recommendation X.690, 2015.
	12. Informative References		12. Informative References
	[CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve		[CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve
	Cryptography (ECC) Algorithms in Cryptographic Message		Cryptography (ECC) Algorithms in Cryptographic Message
	Syntax (CMS)", RFC 5753, January 2010.		Syntax (CMS)", RFC 5753, January 2010.
	[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES)		[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
	Encryption Algorithm in Cryptographic Message Syntax		Encryption Algorithm in Cryptographic Message Syntax
	(CMS)", RFC 3565, July 2003.		(CMS)", RFC 3565, July 2003.
End of changes. 33 change blocks.
	62 lines changed or deleted		64 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/