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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/