< draft-ietf-curdle-cms-ecdh-new-curves-01.txt   draft-ietf-curdle-cms-ecdh-new-curves-02.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended status: Standards Track Vigil Security Intended status: Standards Track Vigil Security
Expires: 8 March 2017 8 September 2016 Expires: 27 September 2017 27 March 2017
Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm Use of the Elliptic Curve Diffie-Hellamn 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-01.txt> <draft-ietf-curdle-cms-ecdh-new-curves-02.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-Hellamn (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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 8 March 2017. This Internet-Draft will expire on 27 September 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 [CURVE]. Those other curves are not deprecated, but support for
curve25519 and curve448 is encouraged. curve25519 and curve448 is encouraged.
When these two curves are used with with Diffie-Hellman key Using curve25519 with Diffie-Hellman key agreement is referred to as
agreement, they are referred to as X25519 and X448. X25519. Using curve448 with Diffie-Hellman key agreement is referred
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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
X25519 is described in Section 6.1 of [CURVE], and X448 is described X25519 is described in Section 6.1 of [CURVE], and X448 is described
in Section 6.2 of [CURVE]. Since curve25519 and curve448 have in Section 6.2 of [CURVE]. 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 [CURVE], implementations MAY detect this
situation by checking for the all-zero output. situation by checking for the all-zero output.
In [CURVE], the shared secret value that is produced by ECDH is In [CURVE], 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 K, the length of the key-encryption pairwise key-encryption key from the shared secret value (K), the
key, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC]. length of the key-encryption key, and the DER-encoded ECC-CMS-
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 {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING } suppPubInfo [2] EXPLICIT OCTET STRING }
The ECC-CMS-SharedInfo keyInfo field contains the object identifier The ECC-CMS-SharedInfo keyInfo field contains the object identifier
of the key-encryption algorithm and associated parameters. This of the key-encryption algorithm and associated parameters. This
algorithm will be used to wrap the content-encryption key. In this algorithm will be used to wrap the content-encryption key. For
specification, the AES Key Wrap algorithm identifier has absent example, the AES Key Wrap algorithm [AESKW] does not need parameters,
parameters. so the algorithm identifier parameters are absent.
The ECC-CMS-SharedInfo entityUInfo field optionally contains The ECC-CMS-SharedInfo entityUInfo field optionally contains
additional keying material supplied by the sending agent. Note that additional keying material supplied by the sending agent. Note that
[CMS] requires implementations to accept a KeyAgreeRecipientInfo [CMS] requires implementations to accept a KeyAgreeRecipientInfo
SEQUENCE that includes the ukm field. If the ukm field is present, 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 the ukm is placed in the entityUInfo field. The ukm value need not
be longer than the key-encryption key that will be produced by the be longer than the key-encryption key that will be produced by the
KDF. When present, the ukm ensures that a different key-encryption KDF. When present, the ukm ensures that a different key-encryption
key is generated, even when the originator ephemeral private key is key is generated, even when the originator ephemeral private key is
improperly used more than once. improperly used more than once.
The ECC-CMS-SharedInfo suppPubInfo field contains the length of the The ECC-CMS-SharedInfo suppPubInfo field contains the length of the
generated key-encryption key, in bits, represented as a 32-bit generated key-encryption key, in bits, represented as a 32-bit
number. For example, the key length for AES-256 would be 0x00000100. number. For example, the key length for AES-256 [AES] would be
0x00000100.
2.1. ANSI-X9.63-KDF 2.1. ANSI-X9.63-KDF
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, generates one or more KM blocks,
with the counter starting at 0x00000001, and incrementing the counter with the counter starting at 0x00000001, and incrementing the counter
for each subsequent KM block until enough material has been for each subsequent KM block until enough material has been
generated. The KM blocks are concatenated left to right: generated. 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) ...
KEK is the pairwise key-encryption key.
2.2. HKDF 2.2. HKDF
The HKDF key derivation function is a robust construct based on a The HKDF key derivation function is a robust construct based on a
one-way hash function described in RFC 5869 [HMAC]. HKDF is one-way hash function described in RFC 5869 [HKDF]. HKDF is
comprised of two steps: HKDF-Extract followed by HKDF-Expand. 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 includes the ukm. This field is The ECC-CMS-SharedInfo structure optionally includes the ukm. If the
optional, and if it is present, the ukm is also used as the HKDF ukm is present, the ukm is also used as the HKDF salt.
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,
once in bits, and once in octets. The ECC-CMS-SharedInfo structure once in bits, and once in octets. The ECC-CMS-SharedInfo structure
includes the length of the generated key-encryption key in bits. The includes the length of the generated key-encryption key in bits. The
HKDF-Expand function takes an argument for the length of the HKDF-Expand function takes an argument for the length of the
generated key-encryption key in octets. generated key-encryption key in octets.
In summary: In summary, to produce the pairwise key-encryption key, KEK:
if ukm is provided, then salt = ukm, else salt = zero if ukm is provided, then salt = ukm, else salt = zero
PRK = HKDF-Extract(salt, K) PRK = HKDF-Extract(salt, K)
KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))
KEK is the pairwise key-encryption key.
3. Enveloped-data Conventions 3. Enveloped-data Conventions
The CMS enveloped-data content type [CMS] consists of an encrypted The CMS enveloped-data content type [CMS] consists of an encrypted
content and wrapped content-encryption keys for one or more content and wrapped content-encryption keys for one or more
recipients. The ECDH key agreement algorithm is used to generate a recipients. The ECDH key agreement algorithm is used to generate a
pairwise key-encryption key between the originator and a particular pairwise key-encryption key between the originator and a particular
recipient. Then, the key-encryption key is used to wrap the content- recipient. Then, the key-encryption key is used to wrap the content-
encryption key for that recipient. When there more than one encryption key for that recipient. When there is more than one
recipient, the same content-encryption key is wrapped for each of recipient, the same content-encryption key MUST be wrapped for each
them. of them.
A compliant implementation MUST meet the requirements for A compliant implementation MUST meet the requirements for
constructing an enveloped-data content type in Section 6 of [CMS]. constructing an enveloped-data content type in Section 6 of [CMS].
A content-encryption key MUST be randomly generated for each instance A content-encryption key MUST be randomly generated for each instance
of an enveloped-data content type. The content-encryption key is of an enveloped-data content type. The content-encryption key is
used to encrypt the content. used to encrypt the content.
3.1. EnvelopedData Fields 3.1. EnvelopedData Fields
skipping to change at page 6, line 4 skipping to change at page 5, line 44
ephemeral key for the originator. The originatorKey algorithm field ephemeral key for the originator. The originatorKey algorithm field
MUST contain the id-ecPublicKey object identifier along with MUST contain the id-ecPublicKey object identifier along with
ECParameters as specified in [PKIXECC]. The originator's ephemeral ECParameters as specified in [PKIXECC]. The originator's ephemeral
public key MUST be encoded using the type ECPoint as specified in public key MUST be encoded using the type ECPoint as specified in
[CMSECC]. As a convenience, the definitions are repeated here: [CMSECC]. As a convenience, the definitions are repeated here:
id-ecPublicKey OBJECT IDENTIFIER ::= { id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
ECPoint ::= OCTET STRING ECPoint ::= OCTET STRING
ECParameters ::= CHOICE { ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL -- implicitCurve NULL --
-- specifiedCurve SpecifiedECDomain -- } -- specifiedCurve SpecifiedECDomain -- }
The object identifiers for X25519 and X448 have been assigned in The object identifiers for X25519 and X448 have been assigned in
[ID.curdle-pkix]. They are repeated below for convenience. [ID.curdle-pkix]. They are repeated below for convenience.
When using X25519, the ECPoint contains exactly 32 octets, and the When using X25519, the ECPoint contains exactly 32 octets, and the
ECParameters namedCurve MUST contain the following object identifier: ECParameters namedCurve MUST contain the following object identifier:
id-X25519 OBJECT IDENTIFIER ::= { 1.3.101.110 } id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
When using X448, the ECPoint contains exactly 56 octets, and the When using X448, the ECPoint contains exactly 56 octets, and the
ECParameters namedCurve MUST contain the following object identifier: ECParameters namedCurve MUST contain the following object identifier:
id-X448 OBJECT IDENTIFIER ::= { 1.3.101.111 } id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires
implementations to accept a KeyAgreeRecipientInfo SEQUENCE that implementations to accept a KeyAgreeRecipientInfo SEQUENCE that
includes the ukm field. If present, the ukm is placed in the includes the ukm field. If present, the ukm is placed in the
entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The
ukm value need not be longer than the key-encryption key produced by ukm value need not be longer than the key-encryption key produced by
the KDF. the KDF.
KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object
identifier of the key-encryption algorithm that will be used to wrap identifier of the key-encryption algorithm that will be used to wrap
skipping to change at page 7, line 5 skipping to change at page 6, line 46
the algorithm specified by the KeyWrapAlgorithm. the algorithm specified by the KeyWrapAlgorithm.
4. Authenticated-data Conventions 4. Authenticated-data Conventions
The CMS authenticated-data content type [CMS] consists an The CMS authenticated-data content type [CMS] consists an
authenticated content, a message authentication code (MAC), and authenticated content, a message authentication code (MAC), and
encrypted authentication keys for one or more recipients. The ECDH encrypted authentication keys for one or more recipients. The ECDH
key agreement algorithm is used to generate a pairwise key-encryption key agreement algorithm is used to generate a pairwise key-encryption
key between the originator and a particular recipient. Then, the key between the originator and a particular recipient. Then, the
key-encryption key is used to wrap the authentication key for that key-encryption key is used to wrap the authentication key for that
recipient. When there more than one recipient, the same recipient. When there is more than one recipient, the same
authentication key is wrapped for each of them. authentication key MUST be wrapped for each of them.
A compliant implementation MUST meet the requirements for A compliant implementation MUST meet the requirements for
constructing an authenticated-data content type in Section 9 of constructing an authenticated-data content type in Section 9 of
[CMS]. [CMS].
A authentication key MUST be randomly generated for each instance of A authentication key MUST be randomly generated for each instance of
an authenticated-data content type. The authentication key is used an authenticated-data content type. The authentication key is used
to compute the MAC over the content. to compute the MAC over the content.
4.1. AuthenticatedData Fields 4.1. AuthenticatedData Fields
skipping to change at page 7, line 30 skipping to change at page 7, line 23
MUST be populated as described in [CMS]; for the recipients that use MUST be populated as described in [CMS]; for the recipients that use
X25519 or X448 the RecipientInfo kari choice MUST be used. X25519 or X448 the RecipientInfo kari choice MUST be used.
4.2. KeyAgreeRecipientInfo Fields 4.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.
5. Authenticated-Enveloped-data Conventions 5. Authenticated-Enveloped-data Conventions
The CMS authenticated-enveloped-data content type content type The CMS authenticated-enveloped-data content type [AUTHENV] consists
[AUTHENV] consists of an authenticated and encrypted content and of an authenticated and encrypted content and encrypted content-
encrypted content-authenticated-encryption keys for one or more authenticated-encryption keys for one or more recipients. The ECDH
recipients. The ECDH key agreement algorithm is used to generate a key agreement algorithm is used to generate a pairwise key-encryption
pairwise key-encryption key between the originator and a particular key between the originator and a particular recipient. Then, the
recipient. Then, the key-encryption key is used to wrap the content- key-encryption key is used to wrap the content-authenticated-
authenticated-encryption key for that recipient. When there more encryption key for that recipient. When there is more than one
than one recipient, the same content-authenticated-encryption key is recipient, the same content-authenticated-encryption key MUST be
wrapped for each of them. wrapped for each of them.
A compliant implementation MUST meet the requirements for A compliant implementation MUST meet the requirements for
constructing an authenticated-data content type in Section 2 of constructing an authenticated-data content type in Section 2 of
[AUTHENV]. [AUTHENV].
A content-authenticated-encryption key MUST be randomly generated for A content-authenticated-encryption key MUST be randomly generated for
each instance of an authenticated-enveloped-data content type. The each instance of an authenticated-enveloped-data content type. The
content-authenticated-encryption key key is used to authenticate and content-authenticated-encryption key key is used to authenticate and
encrypt the content. encrypt the content.
skipping to change at page 8, line 34 skipping to change at page 8, line 30
parameters structure is specified in [PKIXALG], and the namedCurve parameters structure is specified in [PKIXALG], and the namedCurve
alternative MUST be used. The object identifiers from Section 3.2 of alternative MUST be used. The object identifiers from Section 3.2 of
this document are used for X25519 and X448. The EcpkParameters this document are used for X25519 and X448. The EcpkParameters
parameters structure is repeated here for convenience: parameters structure is repeated here for convenience:
EcpkParameters ::= CHOICE { EcpkParameters ::= CHOICE {
ecParameters ECParameters, ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER, namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL } implicitlyCA NULL }
The certificate issuer MAY use indicate the intended usage for the The certificate issuer MAY indicate the intended usage for the
certified public key by including the key usage certificate extension certified public key by including the key usage certificate extension
as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage
extension is present in a certificate that conveys an ECDH static extension is present in a certificate that conveys an ECDH static
public key, then the key usage extension MUST set the keyAgreement public key, then the key usage extension MUST set the keyAgreement
bit. bit.
7. Key Agreement Algorithm Identifiers 7. Key Agreement Algorithm Identifiers
The following object identifiers are assigned in [CMSECC] to indicate
ECDH with ANSI-X9.63-KDF using various one-way hash functions. These
are expected to be used as AlgorithmIdentifiers with a parameter that
specifies the key-encryption algorithm. These are repeated here for
convenience.
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
The following object identifiers are assigned to indicate ECDH with The following object identifiers are assigned to indicate ECDH with
HKDF using various one-way hash functions. These are expected to be HKDF using various one-way hash functions. These are expected to be
used as AlgorithmIdentifiers with a parameter that specifies the key- used as AlgorithmIdentifiers with a parameter that specifies the
encryption algorithm. key-encryption algorithm.
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
TBD0 } smime-alg TBD1 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
TBD1 } smime-alg TBD2 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
TBD2 } smime-alg TBD3 }
8. SMIMECapabilities Attribute Conventions 8. SMIMECapabilities Attribute Conventions
A sending agent MAY announce to other agents that it supports ECDH A sending agent MAY announce to other agents that it supports ECDH
key agreement using the SMIMECapabilities signed attribute in a key agreement using the SMIMECapabilities signed attribute in a
signed message [SMIME] or a certificate [CERTCAP]. Following the signed message [SMIME] or a certificate [CERTCAP]. Following the
pattern established in [CMSECC], the SMIMECapabilities associated pattern established in [CMSECC], the SMIMECapabilities associated
with ECDH carries a DER-encoded object identifier that identifies with ECDH carries a DER-encoded object identifier that identifies
support for ECDH in conjunction with a particular KDF, and it support for ECDH in conjunction with a particular KDF, and it
includes a parameter that names the key wrap algorithm. includes a parameter that names the key wrap algorithm.
skipping to change at page 10, line 49 skipping to change at page 11, line 12
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. If the originator wants to content type, and then it is discarded. If the originator wants to
be able to decrypt the content (for enveloped-data and authenticated- be able to decrypt the content (for enveloped-data and authenticated-
enveloped-data) or check the authentication (for authenticated-data), enveloped-data) or check the authentication (for authenticated-data),
then the originator needs to treat themselves as a recipient. then the originator needs to treat themselves as a recipient.
As specified in [CMS], implementations MUST support processing of the As specified in [CMS], implementations MUST support processing of the
KeyAgreeRecipientInfo ukm field, so interoperability is not a concern KeyAgreeRecipientInfo ukm field; this ensures that interoperability
if the ukm is present or absent. The ukm is placed in the is not a concern whether the ukm is present or absent. The ukm is
entityUInfo field of the ECC-CMS-SharedInfo structure. When present, placed in the entityUInfo field of the ECC-CMS-SharedInfo structure.
the ukm ensures that a different key-encryption key is generated, When present, the ukm ensures that a different key-encryption key is
even when the originator ephemeral private key is improperly used generated, even when the originator ephemeral private key is
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
be assigned in the SMI Security for S/MIME Module Identifiers
(1.2.840.113549.1.9.16.0) registry:
id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
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 are needed. Are they going to come from an IANA in Sections 7 need to be assigned in the SMI Security for S/MIME
registry or from the registry that assigned the object identifiers in Algorithms (1.2.840.113549.1.9.16.3) registry:
[ID.curdle-pkix]?
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD1 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD2 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD3 }
11. Normative References 11. Normative References
[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. November 2007.
[CERTCAP] Santesson, S., "X.509 Certificate Extension for [CERTCAP] Santesson, S., "X.509 Certificate Extension for
Secure/Multipurpose Internet Mail Extensions (S/MIME) Secure/Multipurpose Internet Mail Extensions (S/MIME)
Capabilities", RFC 4262, December 2005. Capabilities", RFC 4262, December 2005.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
5652, September 2009. 5652, September 2009.
[CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
June 2010.
[CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, January 2010.
[CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, January 2016. for Security", RFC 7748, January 2016.
[HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and-
Expand Key Derivation Function (HKDF)", RFC 5869, May Expand Key Derivation Function (HKDF)", RFC 5869, May
2010. 2010.
[ID.curdle-pkix] [ID.curdle-pkix]
Josefsson, S., and J. Schaad, "Algorithm Identifiers for Josefsson, S., and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for
skipping to change at page 12, line 32 skipping to change at page 13, line 27
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, 2015. Recommendation X.680, 2015.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: [X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, 2015.
12. Informative References 12. Informative References
[CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve [AES] National Institute of Standards and Technology. FIPS Pub
Cryptography (ECC) Algorithms in Cryptographic Message 197: Advanced Encryption Standard (AES). 26 November 2001.
Syntax (CMS)", RFC 5753, January 2010.
[AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard
(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.
[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.
13. Acknowledgements Appendix: ASN.1 Module
Thanks to Jim Schaad, Stefan Santesson, Sean Turner for their review CMSECDHAlgs-2017
and insightful suggestions. { 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) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
KeyWrapAlgorithm
FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
KEY-AGREE, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
dhSinglePass-stdDH-sha256kdf-scheme,
dhSinglePass-stdDH-sha384kdf-scheme,
dhSinglePass-stdDH-sha512kdf-scheme,
kaa-dhSinglePass-stdDH-sha256kdf-scheme,
kaa-dhSinglePass-stdDH-sha384kdf-scheme,
kaa-dhSinglePass-stdDH-sha512kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
FROM CMSECCAlgs-2009-02 -- in [CMSECC]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-cms-ecc-alg-2009-02(46) } ;
--
-- Object Identifiers
--
smime-alg OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) }
dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD1 }
dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD2 }
dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
smime-alg TBD3 }
--
-- Extend the Key Agreement Algorithms in [CMSECC]
--
KeyAgreementAlgs KEY-AGREE ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme }
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }
--
-- Extend the S/MIME CAPS in [CMSECC]
--
SMimeCAPS SMIME-CAPS ::= { ...,
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps }
cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme }
cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}
cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }
END
Acknowledgements
Many thanks to Jim Schaad, Stefan Santesson, Sean Turner for their
review and insightful suggestions.
Author Address Author 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. 34 change blocks. 
59 lines changed or deleted 222 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/