 1/draftietfcurdlecmsecdhnewcurves06.txt 20170511 13:13:30.316333597 0700
+++ 2/draftietfcurdlecmsecdhnewcurves07.txt 20170511 13:13:30.348334365 0700
@@ 1,19 +1,19 @@
InternetDraft R. Housley
Intended status: Standards Track Vigil Security
Expires: 10 November 2017 10 May 2017
+Expires: 11 November 2017 11 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 10 November 2017.
+ This InternetDraft will expire on 11 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
@@ 89,25 +89,26 @@
X448 [CURVES].
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 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]. 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 Section 6.2 of [CURVES]. Conforming implementations MUST check
+ whether the computed DiffieHellman shared secret is the allzero
+ value, and abort if so, as described in Section 6 of [CURVES]. If an
+ alternative implementation of these elliptic curves to that
+ documented in Section 6 of [CURVES] is employed, then the additional
+ checks specified in Section 7 of [CURVES] SHOULD be performed.
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.