< draft-ietf-curdle-cms-ecdh-new-curves-02.txt   draft-ietf-curdle-cms-ecdh-new-curves-03.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended status: Standards Track Vigil Security 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 Diffie-Hellamn 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-02.txt> <draft-ietf-curdle-cms-ecdh-new-curves-03.txt>
Abstract Abstract
This document describes the conventions for using Elliptic Curve This document describes the conventions for using Elliptic Curve
Diffie-Hellamn (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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 27 September 2017. This Internet-Draft will expire on 10 October 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
This document describes the conventions for using Elliptic Curve This document describes the conventions for using Elliptic Curve
Diffie-Hellamn (ECDH) key agreement using curve25519 and curve448 Diffie-Hellman (ECDH) key agreement using curve25519 and curve448
[CURVE] in the Cryptographic Message Syntax (CMS) [CMS]. Key [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key
agreement is supported in three CMS content types: the enveloped-data agreement is supported in three CMS content types: the enveloped-data
content type [CMS], authenticated-data content type [CMS], and the content type [CMS], authenticated-data content type [CMS], and the
authenticated-enveloped-data content type [AUTHENV]. authenticated-enveloped-data content type [AUTHENV].
The conventions for using some Elliptic Curve Cryptography (ECC) The conventions for using some Elliptic Curve Cryptography (ECC)
algorithms in CMS are described in [CMSECC]. These conventions cover algorithms in CMS are described in [CMSECC]. These conventions cover
the use of ECDH with some curves other than curve25519 and curve448 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. curve25519 and curve448 is encouraged.
Using curve25519 with Diffie-Hellman key agreement is referred to as Using curve25519 with Diffie-Hellman key agreement is referred to as
X25519. Using curve448 with Diffie-Hellman key agreement is referred X25519. Using curve448 with Diffie-Hellman key agreement is referred
to as X448. to as X448.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS]. document are to be interpreted as described in RFC 2119 [STDWORDS].
1.2. ASN.1 1.2. ASN.1
CMS values are generated using ASN.1 [X680], which uses the Basic CMS values are generated using ASN.1 [X680], which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[X690]. [X690].
2. Key Agreement 2. Key Agreement
In 1976, Diffie and Hellman describe a means for two parties to agree In 1976, Diffie and Hellman described a means for two parties to
upon a shared secret value in manner that prevents eavesdroppers from agree upon a shared secret value in manner that prevents
learning the shared secret value [DH1976]. This secret may then be eavesdroppers from learning the shared secret value [DH1976]. This
converted into pairwise symmetric keying material for use with other secret may then be converted into pairwise symmetric keying material
cryptographic algorithms. Over the years, many variants of this for use with other cryptographic algorithms. Over the years, many
fundamental technique have been developed. This document describes variants of this fundamental technique have been developed. This
the conventions for using Ephemeral-Static Elliptic Curve Diffie- document describes the conventions for using Ephemeral-Static
Hellamn (ECDH) key agreement using X25519 and X448 [CURVE]. Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and
X448 [CURVES].
The originator uses an ephemeral public/private key pair that is The originator uses 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 is used for a single CMS protected
content type, and then it is discarded. The originator obtains the content type, and then it is discarded. The originator obtains the
recipient's static public key from the recipient's certificate recipient's static public key from the recipient's certificate
[PROFILE]. [PROFILE].
X25519 is described in Section 6.1 of [CURVE], and X448 is described X25519 is described in Section 6.1 of [CURVES], and X448 is described
in Section 6.2 of [CURVE]. Since curve25519 and curve448 have in Section 6.2 of [CURVES]. Since curve25519 and curve448 have
cofactors of 8 and 4, respectively, an input point of small order cofactors of 8 and 4, respectively, an input point of small order
will eliminate any contribution from the other party's private key. will eliminate any contribution from the other party's private key.
As described in Section 7 of [CURVE], implementations MAY detect this As described in Section 7 of [CURVES], implementations MAY detect
situation by checking for the all-zero output. this situation by checking for the all-zero 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 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 from the shared secret value (K), the pairwise key-encryption key from the shared secret value (K), the
length of the key-encryption key, and the DER-encoded ECC-CMS- 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.
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
skipping to change at page 4, line 10 skipping to change at page 4, line 16
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
KDF is also described in Section 3.6.1 of [SEC1]. KDF is also described in Section 3.6.1 of [SEC1].
Three values are concatenated to produce the input string to the KDF: Three values are concatenated to produce the input string to the KDF:
1. The shared secret value generated by ECDH, K. 1. The shared secret value generated by ECDH, K.
2. The iteration counter, starting with one, as described below. 2. The iteration counter, starting with one, as described below.
3. The DER-encoded ECC-CMS-SharedInfo structure. 3. The DER-encoded ECC-CMS-SharedInfo structure.
To generate a key-encryption key, generates one or more KM blocks, To generate a key-encryption key (KEK), the KDF generates one or more
with the counter starting at 0x00000001, and incrementing the counter KM blocks, with the counter starting at 0x00000001, and incrementing
for each subsequent KM block until enough material has been the counter for each subsequent KM block until enough material has
generated. The KM blocks are concatenated left to right to produce been generated. The 32-bit counter is represented in network byte
the pairwise key-encryption key, KEK: order. The KM blocks are concatenated left to right to produce the
pairwise key-encryption key, KEK:
KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))
KEK = KM(counter=1) || KM(counter=2) ... KEK = KM(counter=1) || KM(counter=2) ...
2.2. HKDF 2.2. HKDF
The HKDF key derivation function is a robust construct based on a The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a
one-way hash function described in RFC 5869 [HKDF]. HKDF is robust construct based on a one-way hash function described in RFC
comprised of two steps: HKDF-Extract followed by HKDF-Expand. 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed
by HKDF-Expand.
Three values are used as inputs to the HKDF: Three values are used as inputs to the HKDF:
1. The shared secret value generated by ECDH, K. 1. The shared secret value generated by ECDH, K.
2. The length in octets of the keying data to be generated. 2. The length in octets of the keying data to be generated.
3. The DER-encoded ECC-CMS-SharedInfo structure. 3. The DER-encoded ECC-CMS-SharedInfo structure.
The ECC-CMS-SharedInfo structure optionally includes the ukm. If the The ECC-CMS-SharedInfo structure optionally includes the ukm. If the
ukm is present, the ukm is also used as the HKDF salt. ukm is present, the ukm is also used as the HKDF salt.
The length of the generated key-encryption key is used two places, The length of the generated key-encryption key is used two places,
skipping to change at page 8, line 15 skipping to change at page 8, line 26
5.2. KeyAgreeRecipientInfo Fields 5.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 Section 3.2 of this document. described in Section 3.2 of this document.
6. Certificate Conventions 6. Certificate Conventions
RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates
in Internet applications. A recipient static public key is needed in Internet applications. A recipient static public key is needed
for X25519 or X448, and the originator obtains that public key from for X25519 or X448, and the originator obtains that public key from
the recipient's certificate. The conventions in this section augment the recipient's certificate. The conventions for carrying X25519 and
RFC 5280 [PROFILE]. X448 public keys are specified in [ID.curdle-pkix].
The id-ecPublicKey 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.
7. Key Agreement Algorithm Identifiers 7. Key Agreement Algorithm Identifiers
The following object identifiers are assigned in [CMSECC] to indicate The following object identifiers are assigned in [CMSECC] to indicate
ECDH with ANSI-X9.63-KDF using various one-way hash functions. These ECDH with ANSI-X9.63-KDF using various one-way hash functions. These
are expected to be used as AlgorithmIdentifiers with a parameter that are expected to be used as AlgorithmIdentifiers with a parameter that
specifies the key-encryption algorithm. These are repeated here for specifies the key-encryption algorithm. These are repeated here for
convenience. convenience.
secg-scheme OBJECT IDENTIFIER ::= { secg-scheme OBJECT IDENTIFIER ::= {
skipping to change at page 11, line 23 skipping to change at page 11, line 15
is not a concern whether the ukm is present or absent. The ukm is is not a concern whether the ukm is present or absent. The ukm is
placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. placed in the entityUInfo field of the ECC-CMS-SharedInfo structure.
When present, the ukm ensures that a different key-encryption key is When present, the ukm ensures that a different key-encryption key is
generated, even when the originator ephemeral private key is generated, even when the originator ephemeral private key is
improperly used more than once. improperly used more than once.
10. IANA Considerations 10. IANA Considerations
One object identifier for the ASN.1 module in the Appendix needs to One object identifier for the ASN.1 module in the Appendix needs to
be assigned in the SMI Security for S/MIME Module Identifiers 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) [IANA-MOD] registry:
id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) TBD0 } pkcs-9(9) smime(16) mod(0) TBD0 }
Three object identifiers for the Key Agreement Algorithm Identifiers Three object identifiers for the Key Agreement Algorithm Identifiers
in Sections 7 need to be assigned in the SMI Security for S/MIME 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) [IANA-ALG] registry:
smime-alg OBJECT IDENTIFIER ::= { smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) } pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD1 } smime-alg TBD1 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD2 } smime-alg TBD2 }
skipping to change at page 13, line 41 skipping to change at page 13, line 30
(AES) Key Wrap Algorithm", RFC 3394, September 2002. (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, July 2003. (CMS)", RFC 3565, July 2003.
[DH1976] Diffie, W., and M. E. Hellman, "New Directions in [DH1976] Diffie, W., and M. E. Hellman, "New Directions in
Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22,
Nov. 1976, pp. 644-654. Nov. 1976, pp. 644-654.
[IANA-ALG] https://www.iana.org/assignments/smi-numbers/
smi-numbers.xhtml#security-smime-3.
[IANA-MOD] https://www.iana.org/assignments/smi-numbers/
smi-numbers.xhtml#security-smime-0.
[X963] "Public-Key Cryptography for the Financial Services [X963] "Public-Key Cryptography for the Financial Services
Industry: Key Agreement and Key Transport Using Elliptic Industry: Key Agreement and Key Transport Using Elliptic
Curve Cryptography", American National Standard Curve Cryptography", American National Standard
X9.63-2001, 2001. X9.63-2001, 2001.
Appendix: ASN.1 Module Appendix: ASN.1 Module
CMSECDHAlgs-2017 CMSECDHAlgs-2017
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) }
skipping to change at page 14, line 41 skipping to change at page 14, line 41
dhSinglePass-stdDH-sha512kdf-scheme, dhSinglePass-stdDH-sha512kdf-scheme,
kaa-dhSinglePass-stdDH-sha256kdf-scheme, kaa-dhSinglePass-stdDH-sha256kdf-scheme,
kaa-dhSinglePass-stdDH-sha384kdf-scheme, kaa-dhSinglePass-stdDH-sha384kdf-scheme,
kaa-dhSinglePass-stdDH-sha512kdf-scheme, kaa-dhSinglePass-stdDH-sha512kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
FROM CMSECCAlgs-2009-02 -- in [CMSECC] FROM CMSECCAlgs-2009-02 -- in [CMSECC]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) pkcs-9(9) smime(16) modules(0)
id-mod-cms-ecc-alg-2009-02(46) } ; id-mod-cms-ecc-alg-2009-02(46) }
;
-- --
-- Object Identifiers -- Object Identifiers
-- --
smime-alg OBJECT IDENTIFIER ::= { smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) } pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
skipping to change at page 16, line 33 skipping to change at page 16, line 33
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
END END
Acknowledgements Acknowledgements
Many thanks to Jim Schaad, Stefan Santesson, Sean Turner for their Many thanks to Daniel Migault, Jim Schaad, Stefan Santesson, and Sean
review and insightful suggestions. Turner for their review and insightful suggestions.
Author Address Author's Address
Russ Housley Russ Housley
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
housley@vigilsec.com housley@vigilsec.com
 End of changes. 20 change blocks. 
56 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/