 1/draftietfcurdlecmsecdhnewcurves03.txt 20170410 19:13:10.588257987 0700
+++ 2/draftietfcurdlecmsecdhnewcurves04.txt 20170410 19:13:10.620258744 0700
@@ 1,19 +1,19 @@
InternetDraft R. Housley
Intended status: Standards Track Vigil Security
Expires: 10 October 2017 10 April 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
@@ 93,21 +93,21 @@
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].
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 MAY detect
+ As described in Section 7 of [CURVES], implementations SHOULD detect
this situation by checking for the allzero output.
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 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
@@ 128,41 +128,42 @@
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. The ukm value need not
be 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 ECCCMSSharedInfo suppPubInfo field contains the length of the
 generated keyencryption key, in bits, represented as a 32bit
 number. For example, the key length for AES256 [AES] would be
 0x00000100.
+ 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
KDF is also described in Section 3.6.1 of [SEC1].
Three values are concatenated to produce the input string to the KDF:
1. The shared secret value generated by ECDH, K.
2. The iteration counter, starting with one, as described below.
3. The DERencoded ECCCMSSharedInfo structure.
To generate a keyencryption key (KEK), the KDF generates one or more
KM blocks, with the counter starting at 0x00000001, and incrementing
the counter for each subsequent KM block until enough material has
been generated. The 32bit counter is represented in network byte
 order. The KM blocks are concatenated left to right to produce the
 pairwise keyencryption key, KEK:
+ order. The KM blocks are concatenated left to right, and then the
+ leftmost portion of the result is used as the pairwise keyencryption
+ key, KEK:
KM(i) = Hash(K  INT32(counter=i)  DER(ECCCMSSharedInfo))
KEK = KM(counter=1)  KM(counter=2) ...
2.2. HKDF
The HMACbased ExtractandExpand Key Derivation Function (HKDF) is a
robust construct based on a oneway hash function described in RFC
5869 [HKDF]. HKDF is comprised of two steps: HKDFExtract followed
@@ 219,46 +220,34 @@
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
identifying the originator's public key, and the originatorKey
alternative MUST be used. The originatorKey MUST contain an
ephemeral key for the originator. The originatorKey algorithm field
 MUST contain the idecPublicKey object identifier along with
 ECParameters as specified in [PKIXECC]. The originator's ephemeral
 public key MUST be encoded using the type ECPoint as specified in

 [CMSECC]. As a convenience, the definitions are repeated here:

 idecPublicKey OBJECT IDENTIFIER ::= {
 iso(1) memberbody(2) us(840) ansiX962(10045) keyType(2) 1 }

 ECPoint ::= OCTET STRING

 ECParameters ::= CHOICE {
 namedCurve OBJECT IDENTIFIER
  implicitCurve NULL 
  specifiedCurve SpecifiedECDomain  }
+ MUST contain the idX25519 or the idX448 object identifier. The
+ originator's ephemeral public key MUST be encoded as an OCTET STRING.
The object identifiers for X25519 and X448 have been assigned in
+
[ID.curdlepkix]. They are repeated below for convenience.
 When using X25519, the ECPoint contains exactly 32 octets, and the
 ECParameters namedCurve MUST contain the following object identifier:
+ When using X25519, the public key contains exactly 32 octets, and the
+ idX25519 object identifier is used:
idX25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
 When using X448, the ECPoint contains exactly 56 octets, and the
 ECParameters namedCurve MUST contain the following object identifier:
+ When using X448, the public key contains exactly 56 octets, and the
+ idX448 object identifier is used:
idX448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires
implementations to accept a KeyAgreeRecipientInfo SEQUENCE that
includes the ukm field. If present, the ukm is placed in the
entityUInfo field of the ECCCMSSharedInfo as input to the KDF. The
ukm value need not be longer than the keyencryption key produced by
the KDF.