idnits 2.17.00 (12 Aug 2021) /tmp/idnits24275/draft-ietf-curdle-cms-ecdh-new-curves-03.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 (10 April 2017) is 1867 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 119 == Unused Reference: 'PKIXALG' is defined on line 541, 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 (~~), 2 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: 10 October 2017 10 April 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 10 October 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, but support for 62 curve25519 and curve448 is encouraged. 64 Using curve25519 with Diffie-Hellman key agreement is referred to as 65 X25519. Using curve448 with Diffie-Hellman key agreement is referred 66 to as X448. 68 1.1. Terminology 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [STDWORDS]. 74 1.2. ASN.1 76 CMS values are generated using ASN.1 [X680], which uses the Basic 77 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 78 [X690]. 80 2. Key Agreement 82 In 1976, Diffie and Hellman described a means for two parties to 83 agree upon a shared secret value in manner that prevents 84 eavesdroppers from learning the shared secret value [DH1976]. This 85 secret may then be converted into pairwise symmetric keying material 86 for use with other cryptographic algorithms. Over the years, many 87 variants of this fundamental technique have been developed. This 88 document describes the conventions for using Ephemeral-Static 89 Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and 90 X448 [CURVES]. 92 The originator uses an ephemeral public/private key pair that is 93 generated on the same elliptic curve as the public key of the 94 recipient. The ephemeral key pair is used for a single CMS protected 95 content type, and then it is discarded. The originator obtains the 96 recipient's static public key from the recipient's certificate 97 [PROFILE]. 99 X25519 is described in Section 6.1 of [CURVES], and X448 is described 100 in Section 6.2 of [CURVES]. Since curve25519 and curve448 have 101 cofactors of 8 and 4, respectively, an input point of small order 102 will eliminate any contribution from the other party's private key. 103 As described in Section 7 of [CURVES], implementations MAY detect 104 this situation by checking for the all-zero output. 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 from the shared secret value (K), the 110 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. The ukm value need not 132 be longer than the key-encryption key that will be produced by the 133 KDF. When present, the ukm ensures that a different key-encryption 134 key is generated, even when the originator ephemeral private key is 135 improperly used more than once. 137 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 138 generated key-encryption key, in bits, represented as a 32-bit 139 number. For example, the key length for AES-256 [AES] would be 140 0x00000100. 142 2.1. ANSI-X9.63-KDF 144 The ANSI-X9.63-KDF key derivation function is a simple construct 145 based on a one-way hash function described in ANS X9.63 [X963]. This 146 KDF is also described in Section 3.6.1 of [SEC1]. 148 Three values are concatenated to produce the input string to the KDF: 149 1. The shared secret value generated by ECDH, K. 150 2. The iteration counter, starting with one, as described below. 151 3. The DER-encoded ECC-CMS-SharedInfo structure. 153 To generate a key-encryption key (KEK), the KDF generates one or more 154 KM blocks, with the counter starting at 0x00000001, and incrementing 155 the counter for each subsequent KM block until enough material has 156 been generated. The 32-bit counter is represented in network byte 157 order. The KM blocks are concatenated left to right to produce the 158 pairwise key-encryption 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. 179 The length of the generated key-encryption key is used two places, 180 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 181 includes the length of the generated key-encryption key in bits. The 182 HKDF-Expand function takes an argument for the length of the 183 generated key-encryption key in octets. 185 In summary, to produce the pairwise key-encryption key, KEK: 187 if ukm is provided, then salt = ukm, else salt = zero 188 PRK = HKDF-Extract(salt, K) 190 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 192 3. Enveloped-data Conventions 194 The CMS enveloped-data content type [CMS] consists of an encrypted 195 content and wrapped content-encryption keys for one or more 196 recipients. The ECDH key agreement algorithm is used to generate a 197 pairwise key-encryption key between the originator and a particular 198 recipient. Then, the key-encryption key is used to wrap the content- 199 encryption key for that recipient. When there is more than one 200 recipient, the same content-encryption key MUST be wrapped for each 201 of them. 203 A compliant implementation MUST meet the requirements for 204 constructing an enveloped-data content type in Section 6 of [CMS]. 206 A content-encryption key MUST be randomly generated for each instance 207 of an enveloped-data content type. The content-encryption key is 208 used to encrypt the content. 210 3.1. EnvelopedData Fields 212 The enveloped-data content type is ASN.1 encoded using the 213 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 214 populated as described in [CMS]; for the recipients that use X25519 215 or X448 the RecipientInfo kari choice MUST be used. 217 3.2. KeyAgreeRecipientInfo Fields 219 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 220 described in this section when X25519 or X448 is employed for one or 221 more recipients. 223 The KeyAgreeRecipientInfo version MUST be 3. 225 The KeyAgreeRecipientInfo originator provides three alternatives for 226 identifying the originator's public key, and the originatorKey 227 alternative MUST be used. The originatorKey MUST contain an 228 ephemeral key for the originator. The originatorKey algorithm field 229 MUST contain the id-ecPublicKey object identifier along with 230 ECParameters as specified in [PKIXECC]. The originator's ephemeral 231 public key MUST be encoded using the type ECPoint as specified in 233 [CMSECC]. As a convenience, the definitions are repeated here: 235 id-ecPublicKey OBJECT IDENTIFIER ::= { 236 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 238 ECPoint ::= OCTET STRING 240 ECParameters ::= CHOICE { 241 namedCurve OBJECT IDENTIFIER 242 -- implicitCurve NULL -- 243 -- specifiedCurve SpecifiedECDomain -- } 245 The object identifiers for X25519 and X448 have been assigned in 246 [ID.curdle-pkix]. They are repeated below for convenience. 248 When using X25519, the ECPoint contains exactly 32 octets, and the 249 ECParameters namedCurve MUST contain the following object identifier: 251 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 253 When using X448, the ECPoint contains exactly 56 octets, and the 254 ECParameters namedCurve MUST contain the following object identifier: 256 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 258 KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires 259 implementations to accept a KeyAgreeRecipientInfo SEQUENCE that 260 includes the ukm field. If present, the ukm is placed in the 261 entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The 262 ukm value need not be longer than the key-encryption key produced by 263 the KDF. 265 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 266 identifier of the key-encryption algorithm that will be used to wrap 267 the content-encryption key. The conventions for using AES-128, 268 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 270 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 271 identifier and encrypted key for one or more recipients. The 272 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 273 the issuerAndSerialNumber identifying the recipient's certificate or 274 the RecipientKeyIdentifier containing the subject key identifier from 275 the recipient's certificate. In both cases, the recipient's 276 certificate contains the recipient's static X25519 or X448 public 277 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 278 encryption key encrypted with the pairwise key-encryption key using 279 the algorithm specified by the KeyWrapAlgorithm. 281 4. Authenticated-data Conventions 283 The CMS authenticated-data content type [CMS] consists an 284 authenticated content, a message authentication code (MAC), and 285 encrypted authentication keys for one or more recipients. The ECDH 286 key agreement algorithm is used to generate a pairwise key-encryption 287 key between the originator and a particular recipient. Then, the 288 key-encryption key is used to wrap the authentication key for that 289 recipient. When there is more than one recipient, the same 290 authentication key MUST be wrapped for each of them. 292 A compliant implementation MUST meet the requirements for 293 constructing an authenticated-data content type in Section 9 of 294 [CMS]. 296 A authentication key MUST be randomly generated for each instance of 297 an authenticated-data content type. The authentication key is used 298 to compute the MAC over the content. 300 4.1. AuthenticatedData Fields 302 The authenticated-data content type is ASN.1 encoded using the 303 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 304 MUST be populated as described in [CMS]; for the recipients that use 305 X25519 or X448 the RecipientInfo kari choice MUST be used. 307 4.2. KeyAgreeRecipientInfo Fields 309 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 310 described in Section 3.2 of this document. 312 5. Authenticated-Enveloped-data Conventions 314 The CMS authenticated-enveloped-data content type [AUTHENV] consists 315 of an authenticated and encrypted content and encrypted content- 316 authenticated-encryption keys for one or more recipients. The ECDH 317 key agreement algorithm is used to generate a pairwise key-encryption 318 key between the originator and a particular recipient. Then, the 319 key-encryption key is used to wrap the content-authenticated- 320 encryption key for that recipient. When there is more than one 321 recipient, the same content-authenticated-encryption key MUST be 322 wrapped for each of them. 324 A compliant implementation MUST meet the requirements for 325 constructing an authenticated-data content type in Section 2 of 326 [AUTHENV]. 328 A content-authenticated-encryption key MUST be randomly generated for 329 each instance of an authenticated-enveloped-data content type. The 330 content-authenticated-encryption key key is used to authenticate and 331 encrypt the content. 333 5.1. AuthEnvelopedData Fields 335 The authenticated-enveloped-data content type is ASN.1 encoded using 336 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 337 syntax MUST be populated as described in [AUTHENV]; for the 338 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 339 be used. 341 5.2. KeyAgreeRecipientInfo Fields 343 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 344 described in Section 3.2 of this document. 346 6. Certificate Conventions 348 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 349 in Internet applications. A recipient static public key is needed 350 for X25519 or X448, and the originator obtains that public key from 351 the recipient's certificate. The conventions for carrying X25519 and 352 X448 public keys are specified in [ID.curdle-pkix]. 354 7. Key Agreement Algorithm Identifiers 356 The following object identifiers are assigned in [CMSECC] to indicate 357 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 358 are expected to be used as AlgorithmIdentifiers with a parameter that 359 specifies the key-encryption algorithm. These are repeated here for 360 convenience. 362 secg-scheme OBJECT IDENTIFIER ::= { 363 iso(1) identified-organization(3) certicom(132) schemes(1) } 365 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 366 secg-scheme 11 1 } 368 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 369 secg-scheme 11 2 } 371 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 372 secg-scheme 11 3 } 374 The following object identifiers are assigned to indicate ECDH with 375 HKDF using various one-way hash functions. These are expected to be 376 used as AlgorithmIdentifiers with a parameter that specifies the 377 key-encryption algorithm. 379 smime-alg OBJECT IDENTIFIER ::= { 380 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 381 pkcs-9(9) smime(16) alg(3) } 383 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 384 smime-alg TBD1 } 386 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 387 smime-alg TBD2 } 389 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 390 smime-alg TBD3 } 392 8. SMIMECapabilities Attribute Conventions 394 A sending agent MAY announce to other agents that it supports ECDH 395 key agreement using the SMIMECapabilities signed attribute in a 396 signed message [SMIME] or a certificate [CERTCAP]. Following the 397 pattern established in [CMSECC], the SMIMECapabilities associated 398 with ECDH carries a DER-encoded object identifier that identifies 399 support for ECDH in conjunction with a particular KDF, and it 400 includes a parameter that names the key wrap algorithm. 402 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 403 might be of interest to implementations that support X25519 and X448: 405 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 406 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 407 01 05 409 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 410 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 411 01 05 413 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 414 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 415 01 05 417 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 418 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 419 01 2D 421 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 422 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 423 01 2D 425 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 426 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 427 01 2D 429 The following SMIMECapabilities values (in hexidecimal) based on the 430 algorithm identifiers in Section 7 of this document might be of 431 interest to implementations that support X25519 and X448: 433 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 434 TBD 436 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 437 TBD 439 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 440 TBD 442 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 443 TBD 445 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 446 TBD 448 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 449 TBD 451 9. Security Considerations 453 Please consult the security considerations of [CMS] for security 454 considerations related to the enveloped-data content type and the 455 authenticated-data content type. 457 Please consult the security considerations of [AUTHENV] for security 458 considerations related to the authenticated-enveloped-data content 459 type. 461 Please consult the security considerations of [CURVES] for security 462 considerations related to the use of X25519 and X448. 464 The originator uses an ephemeral public/private key pair that is 465 generated on the same elliptic curve as the public key of the 466 recipient. The ephemeral key pair is used for a single CMS protected 467 content type, and then it is discarded. If the originator wants to 468 be able to decrypt the content (for enveloped-data and authenticated- 469 enveloped-data) or check the authentication (for authenticated-data), 470 then the originator needs to treat themselves as a recipient. 472 As specified in [CMS], implementations MUST support processing of the 473 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 474 is not a concern whether the ukm is present or absent. The ukm is 475 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 476 When present, the ukm ensures that a different key-encryption key is 477 generated, even when the originator ephemeral private key is 478 improperly used more than once. 480 10. IANA Considerations 482 One object identifier for the ASN.1 module in the Appendix needs to 483 be assigned in the SMI Security for S/MIME Module Identifiers 484 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 486 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 487 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 488 pkcs-9(9) smime(16) mod(0) TBD0 } 490 Three object identifiers for the Key Agreement Algorithm Identifiers 491 in Sections 7 need to be assigned in the SMI Security for S/MIME 492 Algorithms (1.2.840.113549.1.9.16.3) [IANA-ALG] registry: 494 smime-alg OBJECT IDENTIFIER ::= { 495 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 496 pkcs-9(9) smime(16) alg(3) } 498 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 499 smime-alg TBD1 } 501 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 502 smime-alg TBD2 } 504 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 505 smime-alg TBD3 } 507 11. Normative References 509 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 510 Authenticated-Enveloped-Data Content Type", RFC 5083, 511 November 2007. 513 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 514 Secure/Multipurpose Internet Mail Extensions (S/MIME) 515 Capabilities", RFC 4262, December 2005. 517 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 518 5652, September 2009. 520 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 521 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 522 June 2010. 524 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 525 Cryptography (ECC) Algorithms in Cryptographic Message 526 Syntax (CMS)", RFC 5753, January 2010. 528 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 529 for Security", RFC 7748, January 2016. 531 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 532 Expand Key Derivation Function (HKDF)", RFC 5869, May 533 2010. 535 [ID.curdle-pkix] 536 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 537 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 538 use in the Internet X.509 Public Key Infrastructure", 539 15 August 2016, Work-in-progress. 541 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 542 Identifiers for the Internet X.509 Public Key 543 Infrastructure Certificate and Certificate Revocation List 544 (CRL) Profile", RFC 3279, April 2002. 546 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 547 "Elliptic Curve Cryptography Subject Public Key 548 Information", RFC 5480, March 2009. 550 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 551 Housley, R., and W. Polk, "Internet X.509 Public Key 552 Infrastructure Certificate and Certificate Revocation List 553 (CRL) Profile", RFC 5280, May 2008. 555 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 556 Elliptic Curve Cryptography", version 2.0, May 2009, 557 . 559 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 560 Mail Extensions (S/MIME) Version 3.2 Message 561 Specification", RFC 5751, January 2010. 563 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 567 One (ASN.1): Specification of basic notation", ITU-T 568 Recommendation X.680, 2015. 570 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 571 Specification of Basic Encoding Rules (BER), Canonical 572 Encoding Rules (CER) and Distinguished Encoding Rules 573 (DER)", ITU-T Recommendation X.690, 2015. 575 12. Informative References 577 [AES] National Institute of Standards and Technology. FIPS Pub 578 197: Advanced Encryption Standard (AES). 26 November 2001. 580 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 581 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 583 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 584 Encryption Algorithm in Cryptographic Message Syntax 585 (CMS)", RFC 3565, July 2003. 587 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 588 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 589 Nov. 1976, pp. 644-654. 591 [IANA-ALG] https://www.iana.org/assignments/smi-numbers/ 592 smi-numbers.xhtml#security-smime-3. 594 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/ 595 smi-numbers.xhtml#security-smime-0. 597 [X963] "Public-Key Cryptography for the Financial Services 598 Industry: Key Agreement and Key Transport Using Elliptic 599 Curve Cryptography", American National Standard 600 X9.63-2001, 2001. 602 Appendix: ASN.1 Module 604 CMSECDHAlgs-2017 605 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 606 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } 608 DEFINITIONS IMPLICIT TAGS ::= 609 BEGIN 611 -- EXPORTS ALL 613 IMPORTS 615 KeyWrapAlgorithm 616 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 617 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 618 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 620 KEY-AGREE, SMIME-CAPS 621 FROM AlgorithmInformation-2009 -- in [CMSASN1] 622 { iso(1) identified-organization(3) dod(6) internet(1) 623 security(5) mechanisms(5) pkix(7) id-mod(0) 624 id-mod-algorithmInformation-02(58) } 626 dhSinglePass-stdDH-sha256kdf-scheme, 627 dhSinglePass-stdDH-sha384kdf-scheme, 628 dhSinglePass-stdDH-sha512kdf-scheme, 629 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 630 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 631 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 632 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 633 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 634 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 635 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 636 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 637 pkcs-9(9) smime(16) modules(0) 638 id-mod-cms-ecc-alg-2009-02(46) } 639 ; 641 -- 642 -- Object Identifiers 643 -- 645 smime-alg OBJECT IDENTIFIER ::= { 646 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 647 pkcs-9(9) smime(16) alg(3) } 649 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 650 smime-alg TBD1 } 652 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 653 smime-alg TBD2 } 655 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 656 smime-alg TBD3 } 658 -- 659 -- Extend the Key Agreement Algorithms in [CMSECC] 660 -- 662 KeyAgreementAlgs KEY-AGREE ::= { ..., 663 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 664 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 665 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 666 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 667 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 668 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 670 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 671 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 672 PARAMS TYPE KeyWrapAlgorithm ARE required 673 UKM -- TYPE unencoded data -- ARE preferredPresent 674 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 676 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 677 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 678 PARAMS TYPE KeyWrapAlgorithm ARE required 679 UKM -- TYPE unencoded data -- ARE preferredPresent 680 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 682 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 683 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 684 PARAMS TYPE KeyWrapAlgorithm ARE required 685 UKM -- TYPE unencoded data -- ARE preferredPresent 686 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 688 -- 689 -- Extend the S/MIME CAPS in [CMSECC] 690 -- 692 SMimeCAPS SMIME-CAPS ::= { ..., 693 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 694 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 695 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 696 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 697 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 698 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 700 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 701 TYPE KeyWrapAlgorithm 702 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 704 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 705 TYPE KeyWrapAlgorithm 706 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 708 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 709 TYPE KeyWrapAlgorithm 710 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 712 END 714 Acknowledgements 716 Many thanks to Daniel Migault, Jim Schaad, Stefan Santesson, and Sean 717 Turner for their review and insightful suggestions. 719 Author's Address 721 Russ Housley 722 918 Spring Knoll Drive 723 Herndon, VA 20170 724 USA 725 housley@vigilsec.com