 1/draftietfcurdlecmsecdhnewcurves02.txt 20170410 09:13:12.577003269 0700
+++ 2/draftietfcurdlecmsecdhnewcurves03.txt 20170410 09:13:12.609004022 0700
@@ 1,115 +1,116 @@
InternetDraft R. Housley
Intended status: Standards Track Vigil Security
Expires: 27 September 2017 27 March 2017
+Expires: 10 October 2017 10 April 2017
 Use of the Elliptic Curve DiffieHellamn Key Agreement Algorithm
+ 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
 DiffieHellamn (ECDH) key agreement algorithm using curve25519 and
+ 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
provisions of BCP 78 and BCP 79.
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 27 September 2017.
+ This InternetDraft will expire on 10 October 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This document describes the conventions for using Elliptic Curve
 DiffieHellamn (ECDH) key agreement using curve25519 and curve448
 [CURVE] in the Cryptographic Message Syntax (CMS) [CMS]. Key
+ DiffieHellman (ECDH) key agreement using curve25519 and curve448
+ [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key
agreement is supported in three CMS content types: the envelopeddata
content type [CMS], authenticateddata content type [CMS], and the
authenticatedenvelopeddata content type [AUTHENV].
The conventions for using some Elliptic Curve Cryptography (ECC)
algorithms in CMS are described in [CMSECC]. These conventions cover
the use of ECDH with some curves other than curve25519 and curve448
 [CURVE]. Those other curves are not deprecated, but support for
+ [CURVES]. Those other curves are not deprecated, but support for
curve25519 and curve448 is encouraged.
Using curve25519 with DiffieHellman key agreement is referred to as
X25519. Using curve448 with DiffieHellman key agreement is referred
to as X448.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS].
1.2. ASN.1
CMS values are generated using ASN.1 [X680], which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[X690].
2. Key Agreement
 In 1976, Diffie and Hellman describe 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 Diffie
 Hellamn (ECDH) key agreement using X25519 and X448 [CURVE].
+ 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
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 [CURVE], and X448 is described
 in Section 6.2 of [CURVE]. Since curve25519 and curve448 have
+ 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 [CURVE], implementations MAY detect this
 situation by checking for the allzero output.
+ As described in Section 7 of [CURVES], implementations MAY detect
+ this situation by checking for the allzero output.
 In [CURVE], 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 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
convenience.
ECCCMSSharedInfo ::= SEQUENCE {
@@ 142,35 +143,37 @@
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, 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 KM blocks are concatenated left to right to produce
 the pairwise keyencryption key, KEK:
+ 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:
KM(i) = Hash(K  INT32(counter=i)  DER(ECCCMSSharedInfo))
KEK = KM(counter=1)  KM(counter=2) ...
2.2. HKDF
 The HKDF key derivation function is a robust construct based on a
 oneway hash function described in RFC 5869 [HKDF]. HKDF is
 comprised of two steps: HKDFExtract followed by HKDFExpand.
+ 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
+ by HKDFExpand.
Three values are used as inputs to the HKDF:
1. The shared secret value generated by ECDH, K.
2. The length in octets of the keying data to be generated.
3. The DERencoded ECCCMSSharedInfo structure.
The ECCCMSSharedInfo structure optionally includes the ukm. If the
ukm is present, the ukm is also used as the HKDF salt.
The length of the generated keyencryption key is used two places,
@@ 337,41 +341,22 @@
5.2. KeyAgreeRecipientInfo Fields
The fields of the KeyAgreeRecipientInfo syntax MUST be populated as
described in Section 3.2 of this document.
6. Certificate Conventions
RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates
in Internet applications. A recipient static public key is needed
for X25519 or X448, and the originator obtains that public key from
 the recipient's certificate. The conventions in this section augment
 RFC 5280 [PROFILE].

 The idecPublicKey object identifier continues to identify the static
 ECDH public key for the recipient. The associated EcpkParameters
 parameters structure is specified in [PKIXALG], and the namedCurve
 alternative MUST be used. The object identifiers from Section 3.2 of
 this document are used for X25519 and X448. The EcpkParameters
 parameters structure is repeated here for convenience:

 EcpkParameters ::= CHOICE {
 ecParameters ECParameters,
 namedCurve OBJECT IDENTIFIER,
 implicitlyCA NULL }

 The certificate issuer MAY indicate the intended usage for the
 certified public key by including the key usage certificate extension
 as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage
 extension is present in a certificate that conveys an ECDH static
 public key, then the key usage extension MUST set the keyAgreement
 bit.
+ the recipient's certificate. The conventions for carrying X25519 and
+ X448 public keys are specified in [ID.curdlepkix].
7. Key Agreement Algorithm Identifiers
The following object identifiers are assigned in [CMSECC] to indicate
ECDH with ANSIX9.63KDF using various oneway hash functions. These
are expected to be used as AlgorithmIdentifiers with a parameter that
specifies the keyencryption algorithm. These are repeated here for
convenience.
secgscheme OBJECT IDENTIFIER ::= {
@@ 489,29 +474,29 @@
is not a concern whether the ukm is present or absent. The ukm is
placed in the entityUInfo field of the ECCCMSSharedInfo structure.
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.
10. IANA Considerations
One object identifier for the ASN.1 module in the Appendix needs to
be assigned in the SMI Security for S/MIME Module Identifiers
 (1.2.840.113549.1.9.16.0) registry:
+ (1.2.840.113549.1.9.16.0) [IANAMOD] registry:
idmodcmsecdhalg2017 OBJECT IDENTIFIER ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) mod(0) TBD0 }
Three object identifiers for the Key Agreement Algorithm Identifiers
in Sections 7 need to be assigned in the SMI Security for S/MIME
 Algorithms (1.2.840.113549.1.9.16.3) registry:
+ Algorithms (1.2.840.113549.1.9.16.3) [IANAALG] registry:
smimealg OBJECT IDENTIFIER ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) }
dhSinglePassstdDHhkdfsha256scheme OBJECT IDENTIFIER ::= {
smimealg TBD1 }
dhSinglePassstdDHhkdfsha384scheme OBJECT IDENTIFIER ::= {
smimealg TBD2 }
@@ 596,20 +581,26 @@
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, July 2003.
[DH1976] Diffie, W., and M. E. Hellman, "New Directions in
Cryptography", IEEE Trans. on Info. Theory, Vol. IT22,
Nov. 1976, pp. 644654.
+ [IANAALG] https://www.iana.org/assignments/sminumbers/
+ sminumbers.xhtml#securitysmime3.
+
+ [IANAMOD] https://www.iana.org/assignments/sminumbers/
+ sminumbers.xhtml#securitysmime0.
+
[X963] "PublicKey Cryptography for the Financial Services
Industry: Key Agreement and Key Transport Using Elliptic
Curve Cryptography", American National Standard
X9.632001, 2001.
Appendix: ASN.1 Module
CMSECDHAlgs2017
{ iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) modules(0) idmodcmsecdhalg2017(TBD0) }
@@ 637,21 +628,22 @@
dhSinglePassstdDHsha512kdfscheme,
kaadhSinglePassstdDHsha256kdfscheme,
kaadhSinglePassstdDHsha384kdfscheme,
kaadhSinglePassstdDHsha512kdfscheme,
capkaadhSinglePassstdDHsha256kdfscheme,
capkaadhSinglePassstdDHsha384kdfscheme,
capkaadhSinglePassstdDHsha512kdfscheme
FROM CMSECCAlgs200902  in [CMSECC]
{ iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) modules(0)
 idmodcmseccalg200902(46) } ;
+ idmodcmseccalg200902(46) }
+ ;

 Object Identifiers

smimealg OBJECT IDENTIFIER ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) }
dhSinglePassstdDHhkdfsha256scheme OBJECT IDENTIFIER ::= {
@@ 714,20 +706,20 @@
IDENTIFIED BY dhSinglePassstdDHhkdfsha384scheme}
capkaadhSinglePassstdDHhkdfsha512scheme SMIMECAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePassstdDHhkdfsha512scheme }
END
Acknowledgements
 Many thanks to Jim Schaad, Stefan Santesson, Sean Turner for their
 review and insightful suggestions.
+ Many thanks to Daniel Migault, Jim Schaad, Stefan Santesson, and Sean
+ Turner for their review and insightful suggestions.
Author Address
+Author's Address
Russ Housley
918 Spring Knoll Drive
Herndon, VA 20170
USA
housley@vigilsec.com