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/ |