idnits 2.17.00 (12 Aug 2021) /tmp/idnits20545/draft-ietf-curdle-cms-ecdh-new-curves-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 May 2017) is 1841 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 117 -- Looks like a reference, but probably isn't: '2' on line 118 == Unused Reference: 'PKIXALG' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'PKIXECC' is defined on line 532, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5911 (ref. 'CMSASN1') ** Downref: Normative reference to an Informational RFC: RFC 5753 (ref. 'CMSECC') ** Downref: Normative reference to an Informational RFC: RFC 7748 (ref. 'CURVES') ** Downref: Normative reference to an Informational RFC: RFC 5869 (ref. 'HKDF') -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.curdle-pkix' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' ** Obsolete normative reference: RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 6 November 2017 6 May 2017 6 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm 7 with X25519 and X448 in the Cryptographic Message Syntax (CMS) 9 11 Abstract 13 This document describes the conventions for using Elliptic Curve 14 Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and 15 curve448 in the Cryptographic Message Syntax (CMS). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 6 November 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document describes the conventions for using Elliptic Curve 52 Diffie-Hellman (ECDH) key agreement using curve25519 and curve448 53 [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key 54 agreement is supported in three CMS content types: the enveloped-data 55 content type [CMS], authenticated-data content type [CMS], and the 56 authenticated-enveloped-data content type [AUTHENV]. 58 The conventions for using some Elliptic Curve Cryptography (ECC) 59 algorithms in CMS are described in [CMSECC]. These conventions cover 60 the use of ECDH with some curves other than curve25519 and curve448 61 [CURVES]. Those other curves are not deprecated. 63 Using curve25519 with Diffie-Hellman key agreement is referred to as 64 X25519. Using curve448 with Diffie-Hellman key agreement is referred 65 to as X448. 67 1.1. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [STDWORDS]. 73 1.2. ASN.1 75 CMS values are generated using ASN.1 [X680], which uses the Basic 76 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 77 [X690]. 79 2. Key Agreement 81 In 1976, Diffie and Hellman described a means for two parties to 82 agree upon a shared secret value in manner that prevents 83 eavesdroppers from learning the shared secret value [DH1976]. This 84 secret may then be converted into pairwise symmetric keying material 85 for use with other cryptographic algorithms. Over the years, many 86 variants of this fundamental technique have been developed. This 87 document describes the conventions for using Ephemeral-Static 88 Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and 89 X448 [CURVES]. 91 The originator uses an ephemeral public/private key pair that is 92 generated on the same elliptic curve as the public key of the 93 recipient. The ephemeral key pair is used for a single CMS protected 94 content type, and then it is discarded. The originator obtains the 95 recipient's static public key from the recipient's certificate 96 [PROFILE]. 98 X25519 is described in Section 6.1 of [CURVES], and X448 is described 99 in Section 6.2 of [CURVES]. Since curve25519 and curve448 have 100 cofactors of 8 and 4, respectively, an input point of small order 101 will eliminate any contribution from the other party's private key. 102 As described in Section 7 of [CURVES], implementations SHOULD detect 103 this situation by checking for the all-zero output. 105 In [CURVES], the shared secret value that is produced by ECDH is 106 called K. (In some other specifications, the shared secret value is 107 called Z.) A key derivation function (KDF) is used to produce a 108 pairwise key-encryption key (KEK) from the shared secret value (K), 109 the length of the key-encryption key, and the DER-encoded ECC-CMS- 110 SharedInfo structure [CMSECC]. 112 The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for 113 convenience. 115 ECC-CMS-SharedInfo ::= SEQUENCE { 116 keyInfo AlgorithmIdentifier, 117 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 118 suppPubInfo [2] EXPLICIT OCTET STRING } 120 The ECC-CMS-SharedInfo keyInfo field contains the object identifier 121 of the key-encryption algorithm and associated parameters. This 122 algorithm will be used to wrap the content-encryption key. For 123 example, the AES Key Wrap algorithm [AESKW] does not need parameters, 124 so the algorithm identifier parameters are absent. 126 The ECC-CMS-SharedInfo entityUInfo field optionally contains 127 additional keying material supplied by the sending agent. Note that 128 [CMS] requires implementations to accept a KeyAgreeRecipientInfo 129 SEQUENCE that includes the ukm field. If the ukm field is present, 130 the ukm is placed in the entityUInfo field. There is no security 131 benefit to using a ukm value that is longer than the key-encryption 132 key that will be produced by the KDF. When present, the ukm ensures 133 that a different key-encryption key is generated, even when the 134 originator ephemeral private key is improperly used more than once. 136 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 137 generated key-encryption key, in bits, represented as a 32-bit number 138 in network byte order. For example, the key length for AES-256 [AES] 139 would be 0x00000100. 141 2.1. ANSI-X9.63-KDF 143 The ANSI-X9.63-KDF key derivation function is a simple construct 144 based on a one-way hash function described in ANS X9.63 [X963]. This 145 KDF is also described in Section 3.6.1 of [SEC1]. 147 Three values are concatenated to produce the input string to the KDF: 148 1. The shared secret value generated by ECDH, K. 149 2. The iteration counter, starting with one, as described below. 150 3. The DER-encoded ECC-CMS-SharedInfo structure. 152 To generate a key-encryption key (KEK), the KDF generates one or more 153 KM blocks, with the counter starting at 0x00000001, and incrementing 154 the counter for each subsequent KM block until enough material has 155 been generated. The 32-bit counter is represented in network byte 156 order. The KM blocks are concatenated left to right, and then the 157 leftmost portion of the result is used as the pairwise key-encryption 158 key, KEK: 160 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 162 KEK = KM(counter=1) || KM(counter=2) ... 164 2.2. HKDF 166 The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a 167 robust construct based on a one-way hash function described in RFC 168 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed 169 by HKDF-Expand. 171 Three values are used as inputs to the HKDF: 172 1. The shared secret value generated by ECDH, K. 173 2. The length in octets of the keying data to be generated. 174 3. The DER-encoded ECC-CMS-SharedInfo structure. 176 The ECC-CMS-SharedInfo structure optionally includes the ukm. If the 177 ukm is present, the ukm is also used as the HKDF salt. HKDF uses an 178 appropriate number of zero octets when no salt is provided. 180 The length of the generated key-encryption key is used two places, 181 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 182 includes the length of the generated key-encryption key in bits. The 183 HKDF-Expand function takes an argument for the length of the 184 generated key-encryption key in octets. 186 In summary, to produce the pairwise key-encryption key, KEK: 188 if ukm is provided, then salt = ukm, else salt is not provided 189 PRK = HKDF-Extract(salt, K) 191 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 193 3. Enveloped-data Conventions 195 The CMS enveloped-data content type [CMS] consists of an encrypted 196 content and wrapped content-encryption keys for one or more 197 recipients. The ECDH key agreement algorithm is used to generate a 198 pairwise key-encryption key between the originator and a particular 199 recipient. Then, the key-encryption key is used to wrap the content- 200 encryption key for that recipient. When there is more than one 201 recipient, the same content-encryption key MUST be wrapped for each 202 of them. 204 A compliant implementation MUST meet the requirements for 205 constructing an enveloped-data content type in Section 6 of [CMS]. 207 A content-encryption key MUST be randomly generated for each instance 208 of an enveloped-data content type. The content-encryption key is 209 used to encrypt the content. 211 3.1. EnvelopedData Fields 213 The enveloped-data content type is ASN.1 encoded using the 214 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 215 populated as described in [CMS]; for the recipients that use X25519 216 or X448 the RecipientInfo kari choice MUST be used. 218 3.2. KeyAgreeRecipientInfo Fields 220 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 221 described in this section when X25519 or X448 is employed for one or 222 more recipients. 224 The KeyAgreeRecipientInfo version MUST be 3. 226 The KeyAgreeRecipientInfo originator provides three alternatives for 227 identifying the originator's public key, and the originatorKey 228 alternative MUST be used. The originatorKey MUST contain an 229 ephemeral key for the originator. The originatorKey algorithm field 230 MUST contain the id-X25519 or the id-X448 object identifier. The 231 originator's ephemeral public key MUST be encoded as an OCTET STRING. 233 The object identifiers for X25519 and X448 have been assigned in 234 [ID.curdle-pkix]. They are repeated below for convenience. 236 When using X25519, the public key contains exactly 32 octets, and the 237 id-X25519 object identifier is used: 239 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 241 When using X448, the public key contains exactly 56 octets, and the 242 id-X448 object identifier is used: 244 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 246 KeyAgreeRecipientInfo ukm is optional. The processing of the ukm 247 with The ANSI-X9.63-KDF key derivation function is described in 248 Section 2.1, and the processing of the ukm with the HKDF key 249 derivation function is described in Section 2.2. 251 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 252 identifier of the key-encryption algorithm that will be used to wrap 253 the content-encryption key. The conventions for using AES-128, 254 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 256 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 257 identifier and encrypted key for one or more recipients. The 258 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 259 the issuerAndSerialNumber identifying the recipient's certificate or 260 the RecipientKeyIdentifier containing the subject key identifier from 261 the recipient's certificate. In both cases, the recipient's 262 certificate contains the recipient's static X25519 or X448 public 263 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 264 encryption key encrypted with the pairwise key-encryption key using 265 the algorithm specified by the KeyWrapAlgorithm. 267 4. Authenticated-data Conventions 269 The CMS authenticated-data content type [CMS] consists an 270 authenticated content, a message authentication code (MAC), and 271 encrypted authentication keys for one or more recipients. The ECDH 272 key agreement algorithm is used to generate a pairwise key-encryption 273 key between the originator and a particular recipient. Then, the 274 key-encryption key is used to wrap the authentication key for that 275 recipient. When there is more than one recipient, the same 276 authentication key MUST be wrapped for each of them. 278 A compliant implementation MUST meet the requirements for 279 constructing an authenticated-data content type in Section 9 of 280 [CMS]. 282 A authentication key MUST be randomly generated for each instance of 283 an authenticated-data content type. The authentication key is used 284 to compute the MAC over the content. 286 4.1. AuthenticatedData Fields 288 The authenticated-data content type is ASN.1 encoded using the 289 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 290 MUST be populated as described in [CMS]; for the recipients that use 291 X25519 or X448 the RecipientInfo kari choice MUST be used. 293 4.2. KeyAgreeRecipientInfo Fields 295 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 296 described in Section 3.2 of this document. 298 5. Authenticated-Enveloped-data Conventions 300 The CMS authenticated-enveloped-data content type [AUTHENV] consists 301 of an authenticated and encrypted content and encrypted content- 302 authenticated-encryption keys for one or more recipients. The ECDH 303 key agreement algorithm is used to generate a pairwise key-encryption 304 key between the originator and a particular recipient. Then, the 305 key-encryption key is used to wrap the content-authenticated- 306 encryption key for that recipient. When there is more than one 307 recipient, the same content-authenticated-encryption key MUST be 308 wrapped for each of them. 310 A compliant implementation MUST meet the requirements for 311 constructing an authenticated-data content type in Section 2 of 312 [AUTHENV]. 314 A content-authenticated-encryption key MUST be randomly generated for 315 each instance of an authenticated-enveloped-data content type. The 316 content-authenticated-encryption key is used to authenticate and 317 encrypt the content. 319 5.1. AuthEnvelopedData Fields 321 The authenticated-enveloped-data content type is ASN.1 encoded using 322 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 323 syntax MUST be populated as described in [AUTHENV]; for the 324 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 325 be used. 327 5.2. KeyAgreeRecipientInfo Fields 329 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 330 described in Section 3.2 of this document. 332 6. Certificate Conventions 334 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 335 in Internet applications. A recipient static public key is needed 336 for X25519 or X448, and the originator obtains that public key from 337 the recipient's certificate. The conventions for carrying X25519 and 338 X448 public keys are specified in [ID.curdle-pkix]. 340 7. Key Agreement Algorithm Identifiers 342 The following object identifiers are assigned in [CMSECC] to indicate 343 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 344 are expected to be used as AlgorithmIdentifiers with a parameter that 345 specifies the key-encryption algorithm. These are repeated here for 346 convenience. 348 secg-scheme OBJECT IDENTIFIER ::= { 349 iso(1) identified-organization(3) certicom(132) schemes(1) } 351 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 352 secg-scheme 11 1 } 354 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 355 secg-scheme 11 2 } 357 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 358 secg-scheme 11 3 } 360 The following object identifiers are assigned to indicate ECDH with 361 HKDF using various one-way hash functions. These are expected to be 362 used as AlgorithmIdentifiers with a parameter that specifies the 363 key-encryption algorithm. 365 smime-alg OBJECT IDENTIFIER ::= { 366 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 367 pkcs-9(9) smime(16) alg(3) } 369 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 370 smime-alg TBD1 } 372 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 373 smime-alg TBD2 } 375 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 376 smime-alg TBD3 } 378 8. SMIMECapabilities Attribute Conventions 380 A sending agent MAY announce to other agents that it supports ECDH 381 key agreement using the SMIMECapabilities signed attribute in a 382 signed message [SMIME] or a certificate [CERTCAP]. Following the 383 pattern established in [CMSECC], the SMIMECapabilities associated 384 with ECDH carries a DER-encoded object identifier that identifies 385 support for ECDH in conjunction with a particular KDF, and it 386 includes a parameter that names the key wrap algorithm. 388 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 389 might be of interest to implementations that support X25519 and X448: 391 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 392 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 393 01 05 395 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 396 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 397 01 05 399 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 400 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 401 01 05 403 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 404 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 405 01 2D 407 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 408 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 409 01 2D 411 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 412 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 413 01 2D 415 The following SMIMECapabilities values (in hexidecimal) based on the 416 algorithm identifiers in Section 7 of this document might be of 417 interest to implementations that support X25519 and X448: 419 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 420 TBD 422 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 423 TBD 425 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 426 TBD 428 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 429 TBD 431 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 432 TBD 434 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 435 TBD 437 9. Security Considerations 439 Please consult the security considerations of [CMS] for security 440 considerations related to the enveloped-data content type and the 441 authenticated-data content type. 443 Please consult the security considerations of [AUTHENV] for security 444 considerations related to the authenticated-enveloped-data content 445 type. 447 Please consult the security considerations of [CURVES] for security 448 considerations related to the use of X25519 and X448. 450 The originator uses an ephemeral public/private key pair that is 451 generated on the same elliptic curve as the public key of the 452 recipient. The ephemeral key pair is used for a single CMS protected 453 content type, and then it is discarded. If the originator wants to 454 be able to decrypt the content (for enveloped-data and authenticated- 455 enveloped-data) or check the authentication (for authenticated-data), 456 then the originator needs to treat themselves as a recipient. 458 As specified in [CMS], implementations MUST support processing of the 459 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 460 is not a concern whether the ukm is present or absent. The ukm is 461 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 462 When present, the ukm ensures that a different key-encryption key is 463 generated, even when the originator ephemeral private key is 464 improperly used more than once. 466 10. IANA Considerations 468 One object identifier for the ASN.1 module in the Appendix needs to 469 be assigned in the SMI Security for S/MIME Module Identifiers 470 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 472 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 473 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 474 pkcs-9(9) smime(16) mod(0) TBD0 } 476 Three object identifiers for the Key Agreement Algorithm Identifiers 477 in Sections 7 need to be assigned in the SMI Security for S/MIME 478 Algorithms (1.2.840.113549.1.9.16.3) [IANA-ALG] registry: 480 smime-alg OBJECT IDENTIFIER ::= { 481 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 482 pkcs-9(9) smime(16) alg(3) } 484 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 485 smime-alg TBD1 } 487 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 488 smime-alg TBD2 } 490 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 491 smime-alg TBD3 } 493 11. Normative References 495 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 496 Authenticated-Enveloped-Data Content Type", RFC 5083, 497 November 2007. 499 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 500 Secure/Multipurpose Internet Mail Extensions (S/MIME) 501 Capabilities", RFC 4262, December 2005. 503 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 504 5652, September 2009. 506 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 507 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 508 June 2010. 510 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 511 Cryptography (ECC) Algorithms in Cryptographic Message 512 Syntax (CMS)", RFC 5753, January 2010. 514 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 515 for Security", RFC 7748, January 2016. 517 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 518 Expand Key Derivation Function (HKDF)", RFC 5869, May 519 2010. 521 [ID.curdle-pkix] 522 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 523 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 524 use in the Internet X.509 Public Key Infrastructure", 525 15 August 2016, Work-in-progress. 527 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 528 Identifiers for the Internet X.509 Public Key 529 Infrastructure Certificate and Certificate Revocation List 530 (CRL) Profile", RFC 3279, April 2002. 532 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 533 "Elliptic Curve Cryptography Subject Public Key 534 Information", RFC 5480, March 2009. 536 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 537 Housley, R., and W. Polk, "Internet X.509 Public Key 538 Infrastructure Certificate and Certificate Revocation List 539 (CRL) Profile", RFC 5280, May 2008. 541 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 542 Elliptic Curve Cryptography", version 2.0, May 2009, 543 . 545 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 546 Mail Extensions (S/MIME) Version 3.2 Message 547 Specification", RFC 5751, January 2010. 549 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 553 One (ASN.1): Specification of basic notation", ITU-T 554 Recommendation X.680, 2015. 556 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 557 Specification of Basic Encoding Rules (BER), Canonical 558 Encoding Rules (CER) and Distinguished Encoding Rules 559 (DER)", ITU-T Recommendation X.690, 2015. 561 12. Informative References 563 [AES] National Institute of Standards and Technology. FIPS Pub 564 197: Advanced Encryption Standard (AES). 26 November 2001. 566 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 567 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 569 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 570 Encryption Algorithm in Cryptographic Message Syntax 571 (CMS)", RFC 3565, July 2003. 573 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 574 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 575 Nov. 1976, pp. 644-654. 577 [IANA-ALG] https://www.iana.org/assignments/smi-numbers/ 578 smi-numbers.xhtml#security-smime-3. 580 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/ 581 smi-numbers.xhtml#security-smime-0. 583 [X963] "Public-Key Cryptography for the Financial Services 584 Industry: Key Agreement and Key Transport Using Elliptic 585 Curve Cryptography", American National Standard 586 X9.63-2001, 2001. 588 Appendix: ASN.1 Module 590 CMSECDHAlgs-2017 591 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 592 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } 594 DEFINITIONS IMPLICIT TAGS ::= 595 BEGIN 597 -- EXPORTS ALL 599 IMPORTS 601 KeyWrapAlgorithm 602 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 603 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 604 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 606 KEY-AGREE, SMIME-CAPS 607 FROM AlgorithmInformation-2009 -- in [CMSASN1] 608 { iso(1) identified-organization(3) dod(6) internet(1) 609 security(5) mechanisms(5) pkix(7) id-mod(0) 610 id-mod-algorithmInformation-02(58) } 612 dhSinglePass-stdDH-sha256kdf-scheme, 613 dhSinglePass-stdDH-sha384kdf-scheme, 614 dhSinglePass-stdDH-sha512kdf-scheme, 615 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 616 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 617 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 618 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 619 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 620 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 621 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 622 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 623 pkcs-9(9) smime(16) modules(0) 624 id-mod-cms-ecc-alg-2009-02(46) } 625 ; 627 -- 628 -- Object Identifiers 629 -- 631 smime-alg OBJECT IDENTIFIER ::= { 632 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 633 pkcs-9(9) smime(16) alg(3) } 635 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 636 smime-alg TBD1 } 638 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 639 smime-alg TBD2 } 641 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 642 smime-alg TBD3 } 644 -- 645 -- Extend the Key Agreement Algorithms in [CMSECC] 646 -- 648 KeyAgreementAlgs KEY-AGREE ::= { ..., 649 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 650 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 651 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 652 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 653 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 654 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 656 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 657 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 658 PARAMS TYPE KeyWrapAlgorithm ARE required 659 UKM -- TYPE unencoded data -- ARE preferredPresent 660 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 662 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 663 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 664 PARAMS TYPE KeyWrapAlgorithm ARE required 665 UKM -- TYPE unencoded data -- ARE preferredPresent 666 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 668 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 669 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 670 PARAMS TYPE KeyWrapAlgorithm ARE required 671 UKM -- TYPE unencoded data -- ARE preferredPresent 672 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 674 -- 675 -- Extend the S/MIME CAPS in [CMSECC] 676 -- 678 SMimeCAPS SMIME-CAPS ::= { ..., 679 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 680 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 681 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 682 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 683 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 684 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 686 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 687 TYPE KeyWrapAlgorithm 688 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 690 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 691 TYPE KeyWrapAlgorithm 692 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 694 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 695 TYPE KeyWrapAlgorithm 696 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 698 END 700 Acknowledgements 702 Many thanks to Daniel Migault, Eric Rescorla, Jim Schaad, Stefan 703 Santesson, and Sean Turner for their review and insightful 704 suggestions. 706 Author's Address 708 Russ Housley 709 918 Spring Knoll Drive 710 Herndon, VA 20170 711 USA 712 housley@vigilsec.com