idnits 2.17.00 (12 Aug 2021) /tmp/idnits21109/draft-ietf-curdle-cms-ecdh-new-curves-08.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 (2 June 2017) is 1814 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 118 -- Looks like a reference, but probably isn't: '2' on line 226 -- Looks like a reference, but probably isn't: '1' on line 225 -- Looks like a reference, but probably isn't: '3' on line 227 -- Looks like a reference, but probably isn't: '4' on line 228 == Unused Reference: 'PKIXALG' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'PKIXECC' is defined on line 547, 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 (==), 10 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: 2 December 2017 2 June 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 2 December 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 MUST use 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 MUST be used for a single CMS 94 protected content type, and then it MUST be discarded. The 95 originator obtains the recipient's static public key from the 96 recipient's certificate [PROFILE]. 98 X25519 is described in Section 6.1 of [CURVES], and X448 is described 99 in Section 6.2 of [CURVES]. Conforming implementations MUST check 100 whether the computed Diffie-Hellman shared secret is the all-zero 101 value, and abort if so, as described in Section 6 of [CURVES]. If an 102 alternative implementation of these elliptic curves to that 103 documented in Section 6 of [CURVES] is employed, then the additional 104 checks specified in Section 7 of [CURVES] SHOULD be performed. 106 In [CURVES], the shared secret value that is produced by ECDH is 107 called K. (In some other specifications, the shared secret value is 108 called Z.) A key derivation function (KDF) is used to produce a 109 pairwise key-encryption key (KEK) from the shared secret value (K), 110 the length of the key-encryption key, and the DER-encoded ECC-CMS- 111 SharedInfo structure [CMSECC]. 113 The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for 114 convenience. 116 ECC-CMS-SharedInfo ::= SEQUENCE { 117 keyInfo AlgorithmIdentifier, 118 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 119 suppPubInfo [2] EXPLICIT OCTET STRING } 121 The ECC-CMS-SharedInfo keyInfo field contains the object identifier 122 of the key-encryption algorithm and associated parameters. This 123 algorithm will be used to wrap the content-encryption key. For 124 example, the AES Key Wrap algorithm [AESKW] does not need parameters, 125 so the algorithm identifier parameters are absent. 127 The ECC-CMS-SharedInfo entityUInfo field optionally contains 128 additional keying material supplied by the sending agent. Note that 129 [CMS] requires implementations to accept a KeyAgreeRecipientInfo 130 SEQUENCE that includes the ukm field. If the ukm field is present, 131 the ukm is placed in the entityUInfo field. By including the ukm, a 132 different key-encryption key is generated even when the originator 133 ephemeral private key is improperly used more than once. Therefore, 134 if the ukm field is present, it MUST be selected in a manner that 135 provides with very high probability a unique value; however, there is 136 no security benefit to using a ukm value that is longer than the key- 137 encryption key that will be produced by the KDF. 139 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 140 generated key-encryption key, in bits, represented as a 32-bit number 141 in network byte order. For example, the key length for AES-256 [AES] 142 would be 0x00000100. 144 2.1. ANSI-X9.63-KDF 146 The ANSI-X9.63-KDF key derivation function is a simple construct 147 based on a one-way hash function described in American National 148 Standard X9.63 [X963]. This KDF is also described in Section 3.6.1 149 of [SEC1]. 151 Three values are concatenated to produce the input string to the KDF: 152 1. The shared secret value generated by ECDH, K. 153 2. The iteration counter, starting with one, as described below. 154 3. The DER-encoded ECC-CMS-SharedInfo structure. 156 To generate a key-encryption key (KEK), the KDF generates one or more 157 KM blocks, with the counter starting at 0x00000001, and incrementing 158 the counter for each subsequent KM block until enough material has 159 been generated. The 32-bit counter is represented in network byte 160 order. The KM blocks are concatenated left to right, and then the 161 leftmost portion of the result is used as the pairwise key-encryption 162 key, KEK: 164 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 166 KEK = KM(counter=1) || KM(counter=2) ... 168 2.2. HKDF 170 The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a 171 robust construct based on a one-way hash function described in RFC 172 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed 173 by HKDF-Expand. 175 Three values are used as inputs to the HKDF: 176 1. The shared secret value generated by ECDH, K. 177 2. The length in octets of the keying data to be generated. 178 3. The DER-encoded ECC-CMS-SharedInfo structure. 180 The ECC-CMS-SharedInfo structure optionally includes the ukm. If the 181 ukm is present, the ukm is also used as the HKDF salt. HKDF uses an 182 appropriate number of zero octets when no salt is provided. 184 The length of the generated key-encryption key is used two places, 185 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 186 includes the length of the generated key-encryption key in bits. The 187 HKDF-Expand function takes an argument for the length of the 188 generated key-encryption key in octets. 190 In summary, to produce the pairwise key-encryption key, KEK: 192 if ukm is provided, then salt = ukm, else salt is not provided 193 PRK = HKDF-Extract(salt, K) 195 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 197 3. Enveloped-data Conventions 199 The CMS enveloped-data content type [CMS] consists of an encrypted 200 content and wrapped content-encryption keys for one or more 201 recipients. The ECDH key agreement algorithm is used to generate a 202 pairwise key-encryption key between the originator and a particular 203 recipient. Then, the key-encryption key is used to wrap the content- 204 encryption key for that recipient. When there is more than one 205 recipient, the same content-encryption key MUST be wrapped for each 206 of them. 208 A compliant implementation MUST meet the requirements for 209 constructing an enveloped-data content type in Section 6 of [CMS]. 211 A content-encryption key MUST be randomly generated for each instance 212 of an enveloped-data content type. The content-encryption key is 213 used to encrypt the content. 215 3.1. EnvelopedData Fields 217 The enveloped-data content type is ASN.1 encoded using the 218 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 219 populated as described in Section 6 of [CMS]. The RecipientInfo 220 choice is described in Section 6.2 of [CMS], and repeated here for 221 convenience. 223 RecipientInfo ::= CHOICE { 224 ktri KeyTransRecipientInfo, 225 kari [1] KeyAgreeRecipientInfo, 226 kekri [2] KEKRecipientInfo, 227 pwri [3] PasswordRecipientinfo, 228 ori [4] OtherRecipientInfo } 230 For the recipients that use X25519 or X448 the RecipientInfo kari 231 choice MUST be used. 233 3.2. KeyAgreeRecipientInfo Fields 235 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 236 described in this section when X25519 or X448 is employed for one or 237 more recipients. 239 The KeyAgreeRecipientInfo version MUST be 3. 241 The KeyAgreeRecipientInfo originator provides three alternatives for 242 identifying the originator's public key, and the originatorKey 243 alternative MUST be used. The originatorKey MUST contain an 244 ephemeral key for the originator. The originatorKey algorithm field 245 MUST contain the id-X25519 or the id-X448 object identifier. The 246 originator's ephemeral public key MUST be encoded as an OCTET STRING. 248 The object identifiers for X25519 and X448 have been assigned in 249 [ID.curdle-pkix]. They are repeated below for convenience. 251 When using X25519, the public key contains exactly 32 octets, and the 252 id-X25519 object identifier is used: 254 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 256 When using X448, the public key contains exactly 56 octets, and the 257 id-X448 object identifier is used: 259 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 261 KeyAgreeRecipientInfo ukm is optional. The processing of the ukm 262 with The ANSI-X9.63-KDF key derivation function is described in 263 Section 2.1, and the processing of the ukm with the HKDF key 264 derivation function is described in Section 2.2. 266 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 267 identifier of the key-encryption algorithm that will be used to wrap 268 the content-encryption key. The conventions for using AES-128, 269 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 271 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 272 identifier and encrypted key for one or more recipients. The 273 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 274 the issuerAndSerialNumber identifying the recipient's certificate or 275 the RecipientKeyIdentifier containing the subject key identifier from 276 the recipient's certificate. In both cases, the recipient's 277 certificate contains the recipient's static X25519 or X448 public 278 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 279 encryption key encrypted with the pairwise key-encryption key using 280 the algorithm specified by the KeyWrapAlgorithm. 282 4. Authenticated-data Conventions 284 The CMS authenticated-data content type [CMS] consists an 285 authenticated content, a message authentication code (MAC), and 286 encrypted authentication keys for one or more recipients. The ECDH 287 key agreement algorithm is used to generate a pairwise key-encryption 288 key between the originator and a particular recipient. Then, the 289 key-encryption key is used to wrap the authentication key for that 290 recipient. When there is more than one recipient, the same 291 authentication key MUST be wrapped for each of them. 293 A compliant implementation MUST meet the requirements for 294 constructing an authenticated-data content type in Section 9 of 295 [CMS]. 297 A authentication key MUST be randomly generated for each instance of 298 an authenticated-data content type. The authentication key is used 299 to compute the MAC over the content. 301 4.1. AuthenticatedData Fields 303 The authenticated-data content type is ASN.1 encoded using the 304 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 305 MUST be populated as described in [CMS]; for the recipients that use 306 X25519 or X448 the RecipientInfo kari choice MUST be used. 308 4.2. KeyAgreeRecipientInfo Fields 310 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 311 described in Section 3.2 of this document. 313 5. Authenticated-Enveloped-data Conventions 315 The CMS authenticated-enveloped-data content type [AUTHENV] consists 316 of an authenticated and encrypted content and encrypted content- 317 authenticated-encryption keys for one or more recipients. The ECDH 318 key agreement algorithm is used to generate a pairwise key-encryption 319 key between the originator and a particular recipient. Then, the 320 key-encryption key is used to wrap the content-authenticated- 321 encryption key for that recipient. When there is more than one 322 recipient, the same content-authenticated-encryption key MUST be 323 wrapped for each of them. 325 A compliant implementation MUST meet the requirements for 326 constructing an authenticated-data content type in Section 2 of 327 [AUTHENV]. 329 A content-authenticated-encryption key MUST be randomly generated for 330 each instance of an authenticated-enveloped-data content type. The 331 content-authenticated-encryption key is used to authenticate and 332 encrypt the content. 334 5.1. AuthEnvelopedData Fields 336 The authenticated-enveloped-data content type is ASN.1 encoded using 337 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 338 syntax MUST be populated as described in [AUTHENV]; for the 339 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 340 be used. 342 5.2. KeyAgreeRecipientInfo Fields 344 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 345 described in Section 3.2 of this document. 347 6. Certificate Conventions 349 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 350 in Internet applications. A recipient static public key is needed 351 for X25519 or X448, and the originator obtains that public key from 352 the recipient's certificate. The conventions for carrying X25519 and 353 X448 public keys are specified in [ID.curdle-pkix]. 355 7. Key Agreement Algorithm Identifiers 357 The following object identifiers are assigned in [CMSECC] to indicate 358 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 359 are expected to be used as AlgorithmIdentifiers with a parameter that 360 specifies the key-encryption algorithm. These are repeated here for 361 convenience. 363 secg-scheme OBJECT IDENTIFIER ::= { 364 iso(1) identified-organization(3) certicom(132) schemes(1) } 366 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 367 secg-scheme 11 1 } 369 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 370 secg-scheme 11 2 } 372 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 373 secg-scheme 11 3 } 375 The following object identifiers are assigned to indicate ECDH with 376 HKDF using various one-way hash functions. These are expected to be 377 used as AlgorithmIdentifiers with a parameter that specifies the 378 key-encryption algorithm. 380 smime-alg OBJECT IDENTIFIER ::= { 381 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 382 pkcs-9(9) smime(16) alg(3) } 384 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 385 smime-alg TBD1 } 387 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 388 smime-alg TBD2 } 390 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 391 smime-alg TBD3 } 393 8. SMIMECapabilities Attribute Conventions 395 A sending agent MAY announce to other agents that it supports ECDH 396 key agreement using the SMIMECapabilities signed attribute in a 397 signed message [SMIME] or a certificate [CERTCAP]. Following the 398 pattern established in [CMSECC], the SMIMECapabilities associated 399 with ECDH carries a DER-encoded object identifier that identifies 400 support for ECDH in conjunction with a particular KDF, and it 401 includes a parameter that names the key wrap algorithm. 403 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 404 might be of interest to implementations that support X25519 and X448: 406 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 407 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 408 01 05 410 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 411 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 412 01 05 414 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 415 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 416 01 05 418 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 419 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 420 01 2D 422 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 423 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 424 01 2D 426 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 427 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 428 01 2D 430 The following SMIMECapabilities values (in hexidecimal) based on the 431 algorithm identifiers in Section 7 of this document might be of 432 interest to implementations that support X25519 and X448: 434 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 435 TBD 437 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 438 TBD 440 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 441 TBD 443 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 444 TBD 446 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 447 TBD 449 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 450 TBD 452 9. Security Considerations 454 Please consult the security considerations of [CMS] for security 455 considerations related to the enveloped-data content type and the 456 authenticated-data content type. 458 Please consult the security considerations of [AUTHENV] for security 459 considerations related to the authenticated-enveloped-data content 460 type. 462 Please consult the security considerations of [CURVES] for security 463 considerations related to the use of X25519 and X448. 465 The originator uses an ephemeral public/private key pair that is 466 generated on the same elliptic curve as the public key of the 467 recipient. The ephemeral key pair is used for a single CMS protected 468 content type, and then it is discarded. If the originator wants to 469 be able to decrypt the content (for enveloped-data and authenticated- 470 enveloped-data) or check the authentication (for authenticated-data), 471 then the originator needs to treat themselves as a recipient. 473 As specified in [CMS], implementations MUST support processing of the 474 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 475 is not a concern whether the ukm is present or absent. The ukm is 476 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 477 When present, the ukm ensures that a different key-encryption key is 478 generated, even when the originator ephemeral private key is 479 improperly used more than once. 481 10. IANA Considerations 483 One object identifier for the ASN.1 module in the Appendix needs to 484 be assigned in the SMI Security for S/MIME Module Identifiers 485 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 487 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 488 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 489 pkcs-9(9) smime(16) mod(0) TBD0 } 491 Three object identifiers for the Key Agreement Algorithm Identifiers 492 in Sections 7 need to be assigned in the SMI Security for S/MIME 493 Algorithms (1.2.840.113549.1.9.16.3) [IANA-ALG] registry: 495 smime-alg OBJECT IDENTIFIER ::= { 496 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 497 pkcs-9(9) smime(16) alg(3) } 499 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 500 smime-alg TBD1 } 502 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 503 smime-alg TBD2 } 505 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 506 smime-alg TBD3 } 508 11. Normative References 510 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 511 Authenticated-Enveloped-Data Content Type", RFC 5083, 512 November 2007. 514 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 515 Secure/Multipurpose Internet Mail Extensions (S/MIME) 516 Capabilities", RFC 4262, December 2005. 518 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 519 5652, September 2009. 521 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 522 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 523 June 2010. 525 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 526 Cryptography (ECC) Algorithms in Cryptographic Message 527 Syntax (CMS)", RFC 5753, January 2010. 529 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 530 for Security", RFC 7748, January 2016. 532 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 533 Expand Key Derivation Function (HKDF)", RFC 5869, May 534 2010. 536 [ID.curdle-pkix] 537 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 538 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 539 use in the Internet X.509 Public Key Infrastructure", 540 15 August 2016, Work-in-progress. 542 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 543 Identifiers for the Internet X.509 Public Key 544 Infrastructure Certificate and Certificate Revocation List 545 (CRL) Profile", RFC 3279, April 2002. 547 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 548 "Elliptic Curve Cryptography Subject Public Key 549 Information", RFC 5480, March 2009. 551 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 552 Housley, R., and W. Polk, "Internet X.509 Public Key 553 Infrastructure Certificate and Certificate Revocation List 554 (CRL) Profile", RFC 5280, May 2008. 556 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 557 Elliptic Curve Cryptography", version 2.0, May 2009, 558 . 560 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 561 Mail Extensions (S/MIME) Version 3.2 Message 562 Specification", RFC 5751, January 2010. 564 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 568 One (ASN.1): Specification of basic notation", ITU-T 569 Recommendation X.680, 2015. 571 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 572 Specification of Basic Encoding Rules (BER), Canonical 573 Encoding Rules (CER) and Distinguished Encoding Rules 574 (DER)", ITU-T Recommendation X.690, 2015. 576 12. Informative References 578 [AES] National Institute of Standards and Technology. FIPS Pub 579 197: Advanced Encryption Standard (AES). 26 November 2001. 581 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 582 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 584 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 585 Encryption Algorithm in Cryptographic Message Syntax 586 (CMS)", RFC 3565, July 2003. 588 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 589 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 590 Nov. 1976, pp. 644-654. 592 [IANA-ALG] https://www.iana.org/assignments/smi-numbers/ 593 smi-numbers.xhtml#security-smime-3. 595 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/ 596 smi-numbers.xhtml#security-smime-0. 598 [X963] "Public-Key Cryptography for the Financial Services 599 Industry: Key Agreement and Key Transport Using Elliptic 600 Curve Cryptography", American National Standard 601 X9.63-2001, 2001. 603 Appendix: ASN.1 Module 605 CMSECDHAlgs-2017 606 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 607 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } 609 DEFINITIONS IMPLICIT TAGS ::= 610 BEGIN 612 -- EXPORTS ALL 614 IMPORTS 616 KeyWrapAlgorithm 617 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 618 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 619 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 621 KEY-AGREE, SMIME-CAPS 622 FROM AlgorithmInformation-2009 -- in [CMSASN1] 623 { iso(1) identified-organization(3) dod(6) internet(1) 624 security(5) mechanisms(5) pkix(7) id-mod(0) 625 id-mod-algorithmInformation-02(58) } 627 dhSinglePass-stdDH-sha256kdf-scheme, 628 dhSinglePass-stdDH-sha384kdf-scheme, 629 dhSinglePass-stdDH-sha512kdf-scheme, 630 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 631 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 632 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 633 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 634 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 635 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 636 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 637 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 638 pkcs-9(9) smime(16) modules(0) 639 id-mod-cms-ecc-alg-2009-02(46) } 640 ; 642 -- 643 -- Object Identifiers 644 -- 646 smime-alg OBJECT IDENTIFIER ::= { 647 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 648 pkcs-9(9) smime(16) alg(3) } 650 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 651 smime-alg TBD1 } 653 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 654 smime-alg TBD2 } 656 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 657 smime-alg TBD3 } 659 -- 660 -- Extend the Key Agreement Algorithms in [CMSECC] 661 -- 663 KeyAgreementAlgs KEY-AGREE ::= { ..., 664 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 665 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 666 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 667 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 668 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 669 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 671 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 672 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 673 PARAMS TYPE KeyWrapAlgorithm ARE required 674 UKM -- TYPE unencoded data -- ARE preferredPresent 675 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 677 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 678 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 679 PARAMS TYPE KeyWrapAlgorithm ARE required 680 UKM -- TYPE unencoded data -- ARE preferredPresent 681 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 683 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 684 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 685 PARAMS TYPE KeyWrapAlgorithm ARE required 686 UKM -- TYPE unencoded data -- ARE preferredPresent 687 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 689 -- 690 -- Extend the S/MIME CAPS in [CMSECC] 691 -- 693 SMimeCAPS SMIME-CAPS ::= { ..., 694 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 695 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 696 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 697 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 698 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 699 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 701 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 702 TYPE KeyWrapAlgorithm 703 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 705 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 706 TYPE KeyWrapAlgorithm 707 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 709 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 710 TYPE KeyWrapAlgorithm 711 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 713 END 715 Acknowledgements 717 Many thanks to Daniel Migault, Eric Rescorla, Jim Schaad, Stefan 718 Santesson, and Sean Turner for their review and insightful 719 suggestions. 721 Author's Address 723 Russ Housley 724 918 Spring Knoll Drive 725 Herndon, VA 20170 726 USA 727 housley@vigilsec.com