idnits 2.17.1 draft-ietf-curdle-cms-ecdh-new-curves-06.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 May 2017) is 2542 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 224 -- Looks like a reference, but probably isn't: '1' on line 223 -- Looks like a reference, but probably isn't: '3' on line 225 -- Looks like a reference, but probably isn't: '4' on line 226 == Unused Reference: 'PKIXALG' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'PKIXECC' is defined on line 545, 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: 10 November 2017 10 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 10 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 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]. As described in Section 7 of [CURVES], 100 curve25519 and curve448 have cofactors of 8 and 4, respectively, and 101 so an input point of small order will eliminate any contribution from 102 the other party's private key. Conforming implementations MUST check 103 for the all-zero output to prevent this situation. 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. By including the ukm, a 131 different key-encryption key is generated even when the originator 132 ephemeral private key is improperly used more than once. Therefore, 133 if the ukm field is present, it MUST be selected in a manner that 134 provides with very high probability a unique value; however, there is 135 no security benefit to using a ukm value that is longer than the key- 136 encryption key that will be produced by the KDF. 138 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 139 generated key-encryption key, in bits, represented as a 32-bit number 140 in network byte order. For example, the key length for AES-256 [AES] 141 would be 0x00000100. 143 2.1. ANSI-X9.63-KDF 145 The ANSI-X9.63-KDF key derivation function is a simple construct 146 based on a one-way hash function described in ANS X9.63 [X963]. This 147 KDF is also described in Section 3.6.1 of [SEC1]. 149 Three values are concatenated to produce the input string to the KDF: 150 1. The shared secret value generated by ECDH, K. 151 2. The iteration counter, starting with one, as described below. 152 3. The DER-encoded ECC-CMS-SharedInfo structure. 154 To generate a key-encryption key (KEK), the KDF generates one or more 155 KM blocks, with the counter starting at 0x00000001, and incrementing 156 the counter for each subsequent KM block until enough material has 157 been generated. The 32-bit counter is represented in network byte 158 order. The KM blocks are concatenated left to right, and then the 159 leftmost portion of the result is used as the pairwise key-encryption 160 key, KEK: 162 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 164 KEK = KM(counter=1) || KM(counter=2) ... 166 2.2. HKDF 168 The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a 169 robust construct based on a one-way hash function described in RFC 170 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed 171 by HKDF-Expand. 173 Three values are used as inputs to the HKDF: 174 1. The shared secret value generated by ECDH, K. 175 2. The length in octets of the keying data to be generated. 176 3. The DER-encoded ECC-CMS-SharedInfo structure. 178 The ECC-CMS-SharedInfo structure optionally includes the ukm. If the 179 ukm is present, the ukm is also used as the HKDF salt. HKDF uses an 180 appropriate number of zero octets when no salt is provided. 182 The length of the generated key-encryption key is used two places, 183 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 184 includes the length of the generated key-encryption key in bits. The 185 HKDF-Expand function takes an argument for the length of the 186 generated key-encryption key in octets. 188 In summary, to produce the pairwise key-encryption key, KEK: 190 if ukm is provided, then salt = ukm, else salt is not provided 191 PRK = HKDF-Extract(salt, K) 193 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 195 3. Enveloped-data Conventions 197 The CMS enveloped-data content type [CMS] consists of an encrypted 198 content and wrapped content-encryption keys for one or more 199 recipients. The ECDH key agreement algorithm is used to generate a 200 pairwise key-encryption key between the originator and a particular 201 recipient. Then, the key-encryption key is used to wrap the content- 202 encryption key for that recipient. When there is more than one 203 recipient, the same content-encryption key MUST be wrapped for each 204 of them. 206 A compliant implementation MUST meet the requirements for 207 constructing an enveloped-data content type in Section 6 of [CMS]. 209 A content-encryption key MUST be randomly generated for each instance 210 of an enveloped-data content type. The content-encryption key is 211 used to encrypt the content. 213 3.1. EnvelopedData Fields 215 The enveloped-data content type is ASN.1 encoded using the 216 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 217 populated as described in Section 6 of [CMS]. The RecipientInfo 218 choice is described in Section 6.2 of [CMS], and repeated here for 219 convenience. 221 RecipientInfo ::= CHOICE { 222 ktri KeyTransRecipientInfo, 223 kari [1] KeyAgreeRecipientInfo, 224 kekri [2] KEKRecipientInfo, 225 pwri [3] PasswordRecipientinfo, 226 ori [4] OtherRecipientInfo } 228 For the recipients that use X25519 or X448 the RecipientInfo kari 229 choice MUST be used. 231 3.2. KeyAgreeRecipientInfo Fields 233 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 234 described in this section when X25519 or X448 is employed for one or 235 more recipients. 237 The KeyAgreeRecipientInfo version MUST be 3. 239 The KeyAgreeRecipientInfo originator provides three alternatives for 240 identifying the originator's public key, and the originatorKey 241 alternative MUST be used. The originatorKey MUST contain an 242 ephemeral key for the originator. The originatorKey algorithm field 243 MUST contain the id-X25519 or the id-X448 object identifier. The 244 originator's ephemeral public key MUST be encoded as an OCTET STRING. 246 The object identifiers for X25519 and X448 have been assigned in 247 [ID.curdle-pkix]. They are repeated below for convenience. 249 When using X25519, the public key contains exactly 32 octets, and the 250 id-X25519 object identifier is used: 252 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 254 When using X448, the public key contains exactly 56 octets, and the 255 id-X448 object identifier is used: 257 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 259 KeyAgreeRecipientInfo ukm is optional. The processing of the ukm 260 with The ANSI-X9.63-KDF key derivation function is described in 261 Section 2.1, and the processing of the ukm with the HKDF key 262 derivation function is described in Section 2.2. 264 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 265 identifier of the key-encryption algorithm that will be used to wrap 266 the content-encryption key. The conventions for using AES-128, 267 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 269 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 270 identifier and encrypted key for one or more recipients. The 271 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 272 the issuerAndSerialNumber identifying the recipient's certificate or 273 the RecipientKeyIdentifier containing the subject key identifier from 274 the recipient's certificate. In both cases, the recipient's 275 certificate contains the recipient's static X25519 or X448 public 276 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 277 encryption key encrypted with the pairwise key-encryption key using 278 the algorithm specified by the KeyWrapAlgorithm. 280 4. Authenticated-data Conventions 282 The CMS authenticated-data content type [CMS] consists an 283 authenticated content, a message authentication code (MAC), and 284 encrypted authentication keys for one or more recipients. The ECDH 285 key agreement algorithm is used to generate a pairwise key-encryption 286 key between the originator and a particular recipient. Then, the 287 key-encryption key is used to wrap the authentication key for that 288 recipient. When there is more than one recipient, the same 289 authentication key MUST be wrapped for each of them. 291 A compliant implementation MUST meet the requirements for 292 constructing an authenticated-data content type in Section 9 of 293 [CMS]. 295 A authentication key MUST be randomly generated for each instance of 296 an authenticated-data content type. The authentication key is used 297 to compute the MAC over the content. 299 4.1. AuthenticatedData Fields 301 The authenticated-data content type is ASN.1 encoded using the 302 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 303 MUST be populated as described in [CMS]; for the recipients that use 304 X25519 or X448 the RecipientInfo kari choice MUST be used. 306 4.2. KeyAgreeRecipientInfo Fields 308 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 309 described in Section 3.2 of this document. 311 5. Authenticated-Enveloped-data Conventions 313 The CMS authenticated-enveloped-data content type [AUTHENV] consists 314 of an authenticated and encrypted content and encrypted content- 315 authenticated-encryption keys for one or more recipients. The ECDH 316 key agreement algorithm is used to generate a pairwise key-encryption 317 key between the originator and a particular recipient. Then, the 318 key-encryption key is used to wrap the content-authenticated- 319 encryption key for that recipient. When there is more than one 320 recipient, the same content-authenticated-encryption key MUST be 321 wrapped for each of them. 323 A compliant implementation MUST meet the requirements for 324 constructing an authenticated-data content type in Section 2 of 325 [AUTHENV]. 327 A content-authenticated-encryption key MUST be randomly generated for 328 each instance of an authenticated-enveloped-data content type. The 329 content-authenticated-encryption key is used to authenticate and 330 encrypt the content. 332 5.1. AuthEnvelopedData Fields 334 The authenticated-enveloped-data content type is ASN.1 encoded using 335 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 336 syntax MUST be populated as described in [AUTHENV]; for the 337 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 338 be used. 340 5.2. KeyAgreeRecipientInfo Fields 342 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 343 described in Section 3.2 of this document. 345 6. Certificate Conventions 347 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 348 in Internet applications. A recipient static public key is needed 349 for X25519 or X448, and the originator obtains that public key from 350 the recipient's certificate. The conventions for carrying X25519 and 351 X448 public keys are specified in [ID.curdle-pkix]. 353 7. Key Agreement Algorithm Identifiers 355 The following object identifiers are assigned in [CMSECC] to indicate 356 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 357 are expected to be used as AlgorithmIdentifiers with a parameter that 358 specifies the key-encryption algorithm. These are repeated here for 359 convenience. 361 secg-scheme OBJECT IDENTIFIER ::= { 362 iso(1) identified-organization(3) certicom(132) schemes(1) } 364 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 365 secg-scheme 11 1 } 367 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 368 secg-scheme 11 2 } 370 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 371 secg-scheme 11 3 } 373 The following object identifiers are assigned to indicate ECDH with 374 HKDF using various one-way hash functions. These are expected to be 375 used as AlgorithmIdentifiers with a parameter that specifies the 376 key-encryption algorithm. 378 smime-alg OBJECT IDENTIFIER ::= { 379 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 380 pkcs-9(9) smime(16) alg(3) } 382 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 383 smime-alg TBD1 } 385 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 386 smime-alg TBD2 } 388 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 389 smime-alg TBD3 } 391 8. SMIMECapabilities Attribute Conventions 393 A sending agent MAY announce to other agents that it supports ECDH 394 key agreement using the SMIMECapabilities signed attribute in a 395 signed message [SMIME] or a certificate [CERTCAP]. Following the 396 pattern established in [CMSECC], the SMIMECapabilities associated 397 with ECDH carries a DER-encoded object identifier that identifies 398 support for ECDH in conjunction with a particular KDF, and it 399 includes a parameter that names the key wrap algorithm. 401 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 402 might be of interest to implementations that support X25519 and X448: 404 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 405 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 406 01 05 408 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 409 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 410 01 05 412 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 413 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 414 01 05 416 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 417 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 418 01 2D 420 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 421 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 422 01 2D 424 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 425 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 426 01 2D 428 The following SMIMECapabilities values (in hexidecimal) based on the 429 algorithm identifiers in Section 7 of this document might be of 430 interest to implementations that support X25519 and X448: 432 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 433 TBD 435 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 436 TBD 438 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 439 TBD 441 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 442 TBD 444 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 445 TBD 447 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 448 TBD 450 9. Security Considerations 452 Please consult the security considerations of [CMS] for security 453 considerations related to the enveloped-data content type and the 454 authenticated-data content type. 456 Please consult the security considerations of [AUTHENV] for security 457 considerations related to the authenticated-enveloped-data content 458 type. 460 Please consult the security considerations of [CURVES] for security 461 considerations related to the use of X25519 and X448. 463 The originator uses an ephemeral public/private key pair that is 464 generated on the same elliptic curve as the public key of the 465 recipient. The ephemeral key pair is used for a single CMS protected 466 content type, and then it is discarded. If the originator wants to 467 be able to decrypt the content (for enveloped-data and authenticated- 468 enveloped-data) or check the authentication (for authenticated-data), 469 then the originator needs to treat themselves as a recipient. 471 As specified in [CMS], implementations MUST support processing of the 472 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 473 is not a concern whether the ukm is present or absent. The ukm is 474 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 475 When present, the ukm ensures that a different key-encryption key is 476 generated, even when the originator ephemeral private key is 477 improperly used more than once. 479 10. IANA Considerations 481 One object identifier for the ASN.1 module in the Appendix needs to 482 be assigned in the SMI Security for S/MIME Module Identifiers 483 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 485 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 486 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 487 pkcs-9(9) smime(16) mod(0) TBD0 } 489 Three object identifiers for the Key Agreement Algorithm Identifiers 490 in Sections 7 need to be assigned in the SMI Security for S/MIME 491 Algorithms (1.2.840.113549.1.9.16.3) [IANA-ALG] registry: 493 smime-alg OBJECT IDENTIFIER ::= { 494 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 495 pkcs-9(9) smime(16) alg(3) } 497 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 498 smime-alg TBD1 } 500 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 501 smime-alg TBD2 } 503 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 504 smime-alg TBD3 } 506 11. Normative References 508 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 509 Authenticated-Enveloped-Data Content Type", RFC 5083, 510 November 2007. 512 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 513 Secure/Multipurpose Internet Mail Extensions (S/MIME) 514 Capabilities", RFC 4262, December 2005. 516 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 517 5652, September 2009. 519 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 520 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 521 June 2010. 523 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 524 Cryptography (ECC) Algorithms in Cryptographic Message 525 Syntax (CMS)", RFC 5753, January 2010. 527 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 528 for Security", RFC 7748, January 2016. 530 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 531 Expand Key Derivation Function (HKDF)", RFC 5869, May 532 2010. 534 [ID.curdle-pkix] 535 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 536 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 537 use in the Internet X.509 Public Key Infrastructure", 538 15 August 2016, Work-in-progress. 540 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 541 Identifiers for the Internet X.509 Public Key 542 Infrastructure Certificate and Certificate Revocation List 543 (CRL) Profile", RFC 3279, April 2002. 545 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 546 "Elliptic Curve Cryptography Subject Public Key 547 Information", RFC 5480, March 2009. 549 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 550 Housley, R., and W. Polk, "Internet X.509 Public Key 551 Infrastructure Certificate and Certificate Revocation List 552 (CRL) Profile", RFC 5280, May 2008. 554 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 555 Elliptic Curve Cryptography", version 2.0, May 2009, 556 . 558 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 559 Mail Extensions (S/MIME) Version 3.2 Message 560 Specification", RFC 5751, January 2010. 562 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 566 One (ASN.1): Specification of basic notation", ITU-T 567 Recommendation X.680, 2015. 569 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 570 Specification of Basic Encoding Rules (BER), Canonical 571 Encoding Rules (CER) and Distinguished Encoding Rules 572 (DER)", ITU-T Recommendation X.690, 2015. 574 12. Informative References 576 [AES] National Institute of Standards and Technology. FIPS Pub 577 197: Advanced Encryption Standard (AES). 26 November 2001. 579 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 580 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 582 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 583 Encryption Algorithm in Cryptographic Message Syntax 584 (CMS)", RFC 3565, July 2003. 586 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 587 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 588 Nov. 1976, pp. 644-654. 590 [IANA-ALG] https://www.iana.org/assignments/smi-numbers/ 591 smi-numbers.xhtml#security-smime-3. 593 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/ 594 smi-numbers.xhtml#security-smime-0. 596 [X963] "Public-Key Cryptography for the Financial Services 597 Industry: Key Agreement and Key Transport Using Elliptic 598 Curve Cryptography", American National Standard 599 X9.63-2001, 2001. 601 Appendix: ASN.1 Module 603 CMSECDHAlgs-2017 604 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 605 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } 607 DEFINITIONS IMPLICIT TAGS ::= 608 BEGIN 610 -- EXPORTS ALL 612 IMPORTS 614 KeyWrapAlgorithm 615 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 616 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 617 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 619 KEY-AGREE, SMIME-CAPS 620 FROM AlgorithmInformation-2009 -- in [CMSASN1] 621 { iso(1) identified-organization(3) dod(6) internet(1) 622 security(5) mechanisms(5) pkix(7) id-mod(0) 623 id-mod-algorithmInformation-02(58) } 625 dhSinglePass-stdDH-sha256kdf-scheme, 626 dhSinglePass-stdDH-sha384kdf-scheme, 627 dhSinglePass-stdDH-sha512kdf-scheme, 628 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 629 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 630 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 631 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 632 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 633 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 634 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 635 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 636 pkcs-9(9) smime(16) modules(0) 637 id-mod-cms-ecc-alg-2009-02(46) } 638 ; 640 -- 641 -- Object Identifiers 642 -- 644 smime-alg OBJECT IDENTIFIER ::= { 645 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 646 pkcs-9(9) smime(16) alg(3) } 648 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 649 smime-alg TBD1 } 651 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 652 smime-alg TBD2 } 654 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 655 smime-alg TBD3 } 657 -- 658 -- Extend the Key Agreement Algorithms in [CMSECC] 659 -- 661 KeyAgreementAlgs KEY-AGREE ::= { ..., 662 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 663 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 664 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 665 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 666 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 667 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 669 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 670 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 671 PARAMS TYPE KeyWrapAlgorithm ARE required 672 UKM -- TYPE unencoded data -- ARE preferredPresent 673 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 675 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 676 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 677 PARAMS TYPE KeyWrapAlgorithm ARE required 678 UKM -- TYPE unencoded data -- ARE preferredPresent 679 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 681 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 682 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 683 PARAMS TYPE KeyWrapAlgorithm ARE required 684 UKM -- TYPE unencoded data -- ARE preferredPresent 685 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 687 -- 688 -- Extend the S/MIME CAPS in [CMSECC] 689 -- 691 SMimeCAPS SMIME-CAPS ::= { ..., 692 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 693 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 694 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 695 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 696 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 697 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 699 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 700 TYPE KeyWrapAlgorithm 701 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 703 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 704 TYPE KeyWrapAlgorithm 705 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 707 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 708 TYPE KeyWrapAlgorithm 709 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 711 END 713 Acknowledgements 715 Many thanks to Daniel Migault, Eric Rescorla, Jim Schaad, Stefan 716 Santesson, and Sean Turner for their review and insightful 717 suggestions. 719 Author's Address 721 Russ Housley 722 918 Spring Knoll Drive 723 Herndon, VA 20170 724 USA 725 housley@vigilsec.com