 1/draftietfcurdlecmsecdhnewcurves05.txt 20170510 07:13:30.225511427 0700
+++ 2/draftietfcurdlecmsecdhnewcurves06.txt 20170510 07:13:30.289512944 0700
@@ 1,19 +1,19 @@
InternetDraft R. Housley
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 DiffieHellman Key Agreement Algorithm
with X25519 and X448 in the Cryptographic Message Syntax (CMS)

+
Abstract
This document describes the conventions for using Elliptic Curve
DiffieHellman (ECDH) key agreement algorithm using curve25519 and
curve448 in the Cryptographic Message Syntax (CMS).
Status of This Memo
This InternetDraft is submitted in full conformance with the
@@ 22,21 +22,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on 6 November 2017.
+ This InternetDraft will expire on 10 November 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 81,33 +81,33 @@
In 1976, Diffie and Hellman described a means for two parties to
agree upon a shared secret value in manner that prevents
eavesdroppers from learning the shared secret value [DH1976]. This
secret may then be converted into pairwise symmetric keying material
for use with other cryptographic algorithms. Over the years, many
variants of this fundamental technique have been developed. This
document describes the conventions for using EphemeralStatic
Elliptic Curve DiffieHellman (ECDH) key agreement using X25519 and
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
 recipient. The ephemeral key pair is used for a single CMS protected
 content type, and then it is discarded. The originator obtains the
 recipient's static public key from the recipient's certificate
 [PROFILE].
+ recipient. The ephemeral key pair MUST be used for a single CMS
+ protected content type, and then it MUST be discarded. The
+ originator obtains the recipient's static public key from the
+ recipient's certificate [PROFILE].
X25519 is described in Section 6.1 of [CURVES], and X448 is described
 in Section 6.2 of [CURVES]. Since curve25519 and curve448 have
 cofactors of 8 and 4, respectively, an input point of small order
 will eliminate any contribution from the other party's private key.
 As described in Section 7 of [CURVES], implementations SHOULD detect
 this situation by checking for the allzero output.
+ in Section 6.2 of [CURVES]. As described in Section 7 of [CURVES],
+ curve25519 and curve448 have cofactors of 8 and 4, respectively, and
+ so an input point of small order will eliminate any contribution from
+ the other party's private key. Conforming implementations MUST check
+ for the allzero output to prevent this situation.
In [CURVES], the shared secret value that is produced by ECDH is
called K. (In some other specifications, the shared secret value is
called Z.) A key derivation function (KDF) is used to produce a
pairwise keyencryption key (KEK) from the shared secret value (K),
the length of the keyencryption key, and the DERencoded ECCCMS
SharedInfo structure [CMSECC].
The ECCCMSSharedInfo definition from [CMSECC] is repeated here for
convenience.
@@ 120,25 +120,27 @@
The ECCCMSSharedInfo keyInfo field contains the object identifier
of the keyencryption algorithm and associated parameters. This
algorithm will be used to wrap the contentencryption key. For
example, the AES Key Wrap algorithm [AESKW] does not need parameters,
so the algorithm identifier parameters are absent.
The ECCCMSSharedInfo entityUInfo field optionally contains
additional keying material supplied by the sending agent. Note that
[CMS] requires implementations to accept a KeyAgreeRecipientInfo
SEQUENCE that includes the ukm field. If the ukm field is present,
 the ukm is placed in the entityUInfo field. There is no security
 benefit to using a ukm value that is longer than the keyencryption
 key that will be produced by the KDF. When present, the ukm ensures
 that a different keyencryption key is generated, even when the
 originator ephemeral private key is improperly used more than once.
+ the ukm is placed in the entityUInfo field. By including the ukm, a
+ different keyencryption key is generated even when the originator
+ ephemeral private key is improperly used more than once. Therefore,
+ if the ukm field is present, it MUST be selected in a manner that
+ 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 ECCCMSSharedInfo suppPubInfo field contains the length of the
generated keyencryption key, in bits, represented as a 32bit number
in network byte order. For example, the key length for AES256 [AES]
would be 0x00000100.
2.1. ANSIX9.63KDF
The ANSIX9.63KDF key derivation function is a simple construct
based on a oneway hash function described in ANS X9.63 [X963]. This
@@ 205,22 +207,33 @@
constructing an envelopeddata content type in Section 6 of [CMS].
A contentencryption key MUST be randomly generated for each instance
of an envelopeddata content type. The contentencryption key is
used to encrypt the content.
3.1. EnvelopedData Fields
The envelopeddata content type is ASN.1 encoded using the
EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be
 populated as described in [CMS]; for the recipients that use X25519
 or X448 the RecipientInfo kari choice MUST be used.
+ populated as described in Section 6 of [CMS]. The RecipientInfo
+ 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
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as
described in this section when X25519 or X448 is employed for one or
more recipients.
The KeyAgreeRecipientInfo version MUST be 3.
The KeyAgreeRecipientInfo originator provides three alternatives for