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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/