< draft-ietf-curdle-cms-ecdh-new-curves-04.txt   draft-ietf-curdle-cms-ecdh-new-curves-05.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: 6 November 2017 6 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-04.txt> <draft-ietf-curdle-cms-ecdh-new-curves-05.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 10 October 2017. This Internet-Draft will expire on 6 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 17 skipping to change at page 2, line 17
This document describes the conventions for using Elliptic Curve This document describes the conventions for using Elliptic Curve
Diffie-Hellman (ECDH) key agreement using curve25519 and curve448 Diffie-Hellman (ECDH) key agreement using curve25519 and curve448
[CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key
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
[CURVES]. Those other curves are not deprecated, but support for [CURVES]. Those other curves are not deprecated.
curve25519 and curve448 is encouraged.
Using curve25519 with Diffie-Hellman key agreement is referred to as Using curve25519 with Diffie-Hellman key agreement is referred to as
X25519. Using curve448 with Diffie-Hellman key agreement is referred X25519. Using curve448 with Diffie-Hellman key agreement is referred
to as X448. to as 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].
skipping to change at page 3, line 17 skipping to change at page 3, line 15
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 SHOULD 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 (KEK) from the shared secret value (K),
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.
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING } suppPubInfo [2] EXPLICIT OCTET STRING }
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. The ukm value need not the ukm is placed in the entityUInfo field. There is no security
be longer than the key-encryption key that will be produced by the benefit to using a ukm value that is longer than the key-encryption
KDF. When present, the ukm ensures that a different key-encryption key that will be produced by the KDF. When present, the ukm ensures
key is generated, even when the originator ephemeral private key is that a different key-encryption key is generated, even when the
improperly used more than once. originator ephemeral private key is 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 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 4, line 41 skipping to change at page 4, line 35
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
by HKDF-Expand. by HKDF-Expand.
Three values are used as inputs to the HKDF: Three values are used as inputs to the HKDF:
1. The shared secret value generated by ECDH, K. 1. The shared secret value generated by ECDH, K.
2. The length in octets of the keying data to be generated. 2. The length in octets of the keying data to be generated.
3. The DER-encoded ECC-CMS-SharedInfo structure. 3. The DER-encoded ECC-CMS-SharedInfo structure.
The ECC-CMS-SharedInfo structure optionally includes the ukm. If the The ECC-CMS-SharedInfo structure optionally includes the ukm. If the
ukm is present, the ukm is also used as the HKDF salt. ukm is present, the ukm is also used as the HKDF salt. HKDF uses an
appropriate number of zero octets when no salt is provided.
The length of the generated key-encryption key is used two places, The length of the generated key-encryption key is used two places,
once in bits, and once in octets. The ECC-CMS-SharedInfo structure once in bits, and once in octets. The ECC-CMS-SharedInfo structure
includes the length of the generated key-encryption key in bits. The includes the length of the generated key-encryption key in bits. The
HKDF-Expand function takes an argument for the length of the HKDF-Expand function takes an argument for the length of the
generated key-encryption key in octets. generated key-encryption key in octets.
In summary, to produce the pairwise key-encryption key, KEK: In summary, to produce the pairwise key-encryption key, KEK:
if ukm is provided, then salt = ukm, else salt = zero if ukm is provided, then salt = ukm, else salt is not provided
PRK = HKDF-Extract(salt, K) PRK = HKDF-Extract(salt, K)
KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))
3. Enveloped-data Conventions 3. Enveloped-data Conventions
The CMS enveloped-data content type [CMS] consists of an encrypted The CMS enveloped-data content type [CMS] consists of an encrypted
content and wrapped content-encryption keys for one or more content and wrapped content-encryption keys for one or more
recipients. The ECDH key agreement algorithm is used to generate a recipients. The ECDH key agreement algorithm is used to generate a
pairwise key-encryption key between the originator and a particular pairwise key-encryption key between the originator and a particular
skipping to change at page 6, line 4 skipping to change at page 5, line 46
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-X25519 or the id-X448 object identifier. The MUST contain the id-X25519 or the id-X448 object identifier. The
originator's ephemeral public key MUST be encoded as an OCTET STRING. originator's ephemeral public key MUST be encoded as an OCTET STRING.
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 public key contains exactly 32 octets, and the When using X25519, the public key contains exactly 32 octets, and the
id-X25519 object identifier is used: 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 public key contains exactly 56 octets, and the When using X448, the public key contains exactly 56 octets, and the
id-X448 object identifier is used: 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. The processing of the ukm
implementations to accept a KeyAgreeRecipientInfo SEQUENCE that with The ANSI-X9.63-KDF key derivation function is described in
includes the ukm field. If present, the ukm is placed in the Section 2.1, and the processing of the ukm with the HKDF key
entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The derivation function is described in Section 2.2.
ukm value need not be longer than the key-encryption key produced by
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
skipping to change at page 7, line 43 skipping to change at page 7, line 35
encryption key for that recipient. When there is more than one encryption key for that recipient. When there is more than one
recipient, the same content-authenticated-encryption key MUST be recipient, the same content-authenticated-encryption key MUST be
wrapped for each of them. wrapped for each of them.
A compliant implementation MUST meet the requirements for A compliant implementation MUST meet the requirements for
constructing an authenticated-data content type in Section 2 of constructing an authenticated-data content type in Section 2 of
[AUTHENV]. [AUTHENV].
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 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 X25519 or X448 the RecipientInfo kari choice MUST recipients that use X25519 or X448 the RecipientInfo kari choice MUST
be used. be used.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
END END
Acknowledgements Acknowledgements
Many thanks to Daniel Migault, Jim Schaad, Stefan Santesson, and Sean Many thanks to Daniel Migault, Eric Rescorla, Jim Schaad, Stefan
Turner for their review and insightful suggestions. Santesson, and Sean Turner for their review and insightful
suggestions.
Author's Address Author's Address
Russ Housley Russ Housley
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
housley@vigilsec.com housley@vigilsec.com
 End of changes. 12 change blocks. 
24 lines changed or deleted 22 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/