draft-ietf-curdle-cms-ecdh-new-curves-05.txt   draft-ietf-curdle-cms-ecdh-new-curves-06.txt 
Internet-Draft R. Housley Internet-Draft R. Housley
Intended status: Standards Track Vigil Security Intended status: Standards Track Vigil Security
Expires: 6 November 2017 6 May 2017 Expires: 10 November 2017 10 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-05.txt> <draft-ietf-curdle-cms-ecdh-new-curves-06.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 6 November 2017. This Internet-Draft will expire on 10 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 47 skipping to change at page 2, line 47
In 1976, Diffie and Hellman described a means for two parties to In 1976, Diffie and Hellman described a means for two parties to
agree upon a shared secret value in manner that prevents agree upon a shared secret value in manner that prevents
eavesdroppers from learning the shared secret value [DH1976]. This eavesdroppers from learning the shared secret value [DH1976]. This
secret may then be converted into pairwise symmetric keying material secret may then be converted into pairwise symmetric keying material
for use with other cryptographic algorithms. Over the years, many for use with other cryptographic algorithms. Over the years, many
variants of this fundamental technique have been developed. This variants of this fundamental technique have been developed. This
document describes the conventions for using Ephemeral-Static document describes the conventions for using Ephemeral-Static
Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and
X448 [CURVES]. X448 [CURVES].
The originator uses an ephemeral public/private key pair that is The originator MUST use 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 MUST be used for a single CMS
content type, and then it is discarded. The originator obtains the protected content type, and then it MUST be discarded. The
recipient's static public key from the recipient's certificate originator obtains the recipient's static public key from the
[PROFILE]. recipient's certificate [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]. As described in Section 7 of [CURVES],
cofactors of 8 and 4, respectively, an input point of small order curve25519 and curve448 have cofactors of 8 and 4, respectively, and
will eliminate any contribution from the other party's private key. so an input point of small order will eliminate any contribution from
As described in Section 7 of [CURVES], implementations SHOULD detect the other party's private key. Conforming implementations MUST check
this situation by checking for the all-zero output. for the all-zero output to prevent this situation.
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 (KEK) from the shared secret value (K), pairwise key-encryption key (KEK) from the shared secret value (K),
the 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.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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. There is no security the ukm is placed in the entityUInfo field. By including the ukm, a
benefit to using a ukm value that is longer than the key-encryption different key-encryption key is generated even when the originator
key that will be produced by the KDF. When present, the ukm ensures ephemeral private key is improperly used more than once. Therefore,
that a different key-encryption key is generated, even when the if the ukm field is present, it MUST be selected in a manner that
originator ephemeral private key is improperly used more than once. provides with very high probability a unique value; however, there is
no security benefit to using a ukm value that is longer than the key-
encryption key that will be produced by the KDF.
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 5, line 27 skipping to change at page 5, line 34
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 encrypt 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 X25519 populated as described in Section 6 of [CMS]. The RecipientInfo
or X448 the RecipientInfo kari choice MUST be used. choice is described in Section 6.2 of [CMS], and repeated here for
convenience.
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
For the recipients that use X25519 or X448 the RecipientInfo kari
choice MUST be 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 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
 End of changes. 8 change blocks. 
20 lines changed or deleted 33 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/