idnits 2.17.00 (12 Aug 2021) /tmp/idnits58155/draft-ietf-curdle-cms-ecdh-new-curves-10.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 (22 August 2017) is 1726 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 146 -- Looks like a reference, but probably isn't: '2' on line 254 -- Looks like a reference, but probably isn't: '1' on line 253 -- Looks like a reference, but probably isn't: '3' on line 255 -- Looks like a reference, but probably isn't: '4' on line 256 == Unused Reference: 'PKIXALG' is defined on line 576, 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 (==), 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: 22 February 2018 22 August 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 22 February 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 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. ANSI-X9.63-KDF . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. HKDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Enveloped-data Conventions . . . . . . . . . . . . . . . . . . 6 58 3.1. EnvelopedData Fields . . . . . . . . . . . . . . . . . . . 6 59 3.2. KeyAgreeRecipientInfo Fields . . . . . . . . . . . . . . . 7 60 4. Authenticated-data Conventions . . . . . . . . . . . . . . . . 8 61 4.1. AuthenticatedData Fields . . . . . . . . . . . . . . . . . 8 62 4.2. KeyAgreeRecipientInfo Fields . . . . . . . . . . . . . . . 8 63 5. Authenticated-Enveloped-data Conventions . . . . . . . . . . . 8 64 5.1. AuthEnvelopedData Fields . . . . . . . . . . . . . . . . . 9 65 5.2. KeyAgreeRecipientInfo Fields . . . . . . . . . . . . . . . 9 66 6. Certificate Conventions . . . . . . . . . . . . . . . . . . . 9 67 7. Key Agreement Algorithm Identifiers . . . . . . . . . . . . . 9 68 8. SMIMECapabilities Attribute Conventions . . . . . . . . . . . 10 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 72 12. Informative References . . . . . . . . . . . . . . . . . . . 14 73 Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 15 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 This document describes the conventions for using Elliptic Curve 80 Diffie-Hellman (ECDH) key agreement using curve25519 and curve448 81 [CURVES] in the Cryptographic Message Syntax (CMS) [CMS]. Key 82 agreement is supported in three CMS content types: the enveloped-data 83 content type [CMS], authenticated-data content type [CMS], and the 84 authenticated-enveloped-data content type [AUTHENV]. 86 The conventions for using some Elliptic Curve Cryptography (ECC) 87 algorithms in CMS are described in [CMSECC]. These conventions cover 88 the use of ECDH with some curves other than curve25519 and curve448 89 [CURVES]. Those other curves are not deprecated. 91 Using curve25519 with Diffie-Hellman key agreement is referred to as 92 X25519. Using curve448 with Diffie-Hellman key agreement is referred 93 to as X448. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [STDWORDS]. 101 1.2. ASN.1 103 CMS values are generated using ASN.1 [X680], which uses the Basic 104 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 105 [X690]. 107 2. Key Agreement 109 In 1976, Diffie and Hellman described a means for two parties to 110 agree upon a shared secret value in manner that prevents 111 eavesdroppers from learning the shared secret value [DH1976]. This 112 secret may then be converted into pairwise symmetric keying material 113 for use with other cryptographic algorithms. Over the years, many 114 variants of this fundamental technique have been developed. This 115 document describes the conventions for using Ephemeral-Static 116 Elliptic Curve Diffie-Hellman (ECDH) key agreement using X25519 and 117 X448 [CURVES]. 119 The originator MUST use an ephemeral public/private key pair that is 120 generated on the same elliptic curve as the public key of the 121 recipient. The ephemeral key pair MUST be used for a single CMS 122 protected content type, and then it MUST be discarded. The 123 originator obtains the recipient's static public key from the 124 recipient's certificate [PROFILE]. 126 X25519 is described in Section 6.1 of [CURVES], and X448 is described 127 in Section 6.2 of [CURVES]. Conforming implementations MUST check 128 whether the computed Diffie-Hellman shared secret is the all-zero 129 value, and abort if so, as described in Section 6 of [CURVES]. If an 130 alternative implementation of these elliptic curves to that 131 documented in Section 6 of [CURVES] is employed, then the additional 132 checks specified in Section 7 of [CURVES] SHOULD be performed. 134 In [CURVES], the shared secret value that is produced by ECDH is 135 called K. (In some other specifications, the shared secret value is 136 called Z.) A key derivation function (KDF) is used to produce a 137 pairwise key-encryption key (KEK) from the shared secret value (K), 138 the length of the key-encryption key, and the DER-encoded ECC-CMS- 139 SharedInfo structure [CMSECC]. 141 The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for 142 convenience. 144 ECC-CMS-SharedInfo ::= SEQUENCE { 145 keyInfo AlgorithmIdentifier, 146 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 147 suppPubInfo [2] EXPLICIT OCTET STRING } 149 The ECC-CMS-SharedInfo keyInfo field contains the object identifier 150 of the key-encryption algorithm and associated parameters. This 151 algorithm will be used to wrap the content-encryption key. For 152 example, the AES Key Wrap algorithm [AESKW] does not need parameters, 153 so the algorithm identifier parameters are absent. 155 The ECC-CMS-SharedInfo entityUInfo field optionally contains 156 additional keying material supplied by the sending agent. Note that 157 [CMS] requires implementations to accept a KeyAgreeRecipientInfo 158 SEQUENCE that includes the ukm field. If the ukm field is present, 159 the ukm is placed in the entityUInfo field. By including the ukm, a 160 different key-encryption key is generated even when the originator 161 ephemeral private key is improperly used more than once. Therefore, 162 if the ukm field is present, it MUST be selected in a manner that 163 provides with very high probability a unique value; however, there is 164 no security benefit to using a ukm value that is longer than the key- 165 encryption key that will be produced by the KDF. 167 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 168 generated key-encryption key, in bits, represented as a 32-bit number 169 in network byte order. For example, the key length for AES-256 [AES] 170 would be 0x00000100. 172 2.1. ANSI-X9.63-KDF 174 The ANSI-X9.63-KDF key derivation function is a simple construct 175 based on a one-way hash function described in American National 176 Standard X9.63 [X963]. This KDF is also described in Section 3.6.1 177 of [SEC1]. 179 Three values are concatenated to produce the input string to the KDF: 180 1. The shared secret value generated by ECDH, K. 181 2. The iteration counter, starting with one, as described below. 182 3. The DER-encoded ECC-CMS-SharedInfo structure. 184 To generate a key-encryption key (KEK), the KDF generates one or more 185 KM blocks, with the counter starting at 0x00000001, and incrementing 186 the counter for each subsequent KM block until enough material has 187 been generated. The 32-bit counter is represented in network byte 188 order. The KM blocks are concatenated left to right, and then the 189 leftmost portion of the result is used as the pairwise key-encryption 190 key, KEK: 192 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 194 KEK = KM(counter=1) || KM(counter=2) ... 196 2.2. HKDF 198 The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a 199 robust construct based on a one-way hash function described in RFC 200 5869 [HKDF]. HKDF is comprised of two steps: HKDF-Extract followed 201 by HKDF-Expand. 203 Three values are used as inputs to the HKDF: 204 1. The shared secret value generated by ECDH, K. 205 2. The length in octets of the keying data to be generated. 206 3. The DER-encoded ECC-CMS-SharedInfo structure. 208 The ECC-CMS-SharedInfo structure optionally includes the ukm. If the 209 ukm is present, the ukm is also used as the HKDF salt. HKDF uses an 210 appropriate number of zero octets when no salt is provided. 212 The length of the generated key-encryption key is used in two places, 213 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 214 includes the length of the generated key-encryption key in bits. The 215 HKDF-Expand function takes an argument for the length of the 216 generated key-encryption key in octets. 218 In summary, to produce the pairwise key-encryption key, KEK: 220 if ukm is provided, then salt = ukm, else salt is not provided 221 PRK = HKDF-Extract(salt, K) 223 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 225 3. Enveloped-data Conventions 227 The CMS enveloped-data content type [CMS] consists of an encrypted 228 content and wrapped content-encryption keys for one or more 229 recipients. The ECDH key agreement algorithm is used to generate a 230 pairwise key-encryption key between the originator and a particular 231 recipient. Then, the key-encryption key is used to wrap the content- 232 encryption key for that recipient. When there is more than one 233 recipient, the same content-encryption key MUST be wrapped for each 234 of them. 236 A compliant implementation MUST meet the requirements for 237 constructing an enveloped-data content type in Section 6 of [CMS]. 239 A content-encryption key MUST be randomly generated for each instance 240 of an enveloped-data content type. The content-encryption key is 241 used to encrypt the content. 243 3.1. EnvelopedData Fields 245 The enveloped-data content type is ASN.1 encoded using the 246 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 247 populated as described in Section 6 of [CMS]. The RecipientInfo 248 choice is described in Section 6.2 of [CMS], and repeated here for 249 convenience. 251 RecipientInfo ::= CHOICE { 252 ktri KeyTransRecipientInfo, 253 kari [1] KeyAgreeRecipientInfo, 254 kekri [2] KEKRecipientInfo, 255 pwri [3] PasswordRecipientinfo, 256 ori [4] OtherRecipientInfo } 258 For the recipients that use X25519 or X448 the RecipientInfo kari 259 choice MUST be used. 261 3.2. KeyAgreeRecipientInfo Fields 263 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 264 described in this section when X25519 or X448 is employed for one or 265 more recipients. 267 The KeyAgreeRecipientInfo version MUST be 3. 269 The KeyAgreeRecipientInfo originator provides three alternatives for 270 identifying the originator's public key, and the originatorKey 271 alternative MUST be used. The originatorKey MUST contain an 272 ephemeral key for the originator. The originatorKey algorithm field 273 MUST contain the id-X25519 or the id-X448 object identifier. The 274 originator's ephemeral public key MUST be encoded as an OCTET STRING. 276 The object identifiers for X25519 and X448 have been assigned in 277 [ID.curdle-pkix]. They are repeated below for convenience. 279 When using X25519, the public key contains exactly 32 octets, and the 280 id-X25519 object identifier is used: 282 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 284 When using X448, the public key contains exactly 56 octets, and the 285 id-X448 object identifier is used: 287 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 289 KeyAgreeRecipientInfo ukm is optional. The processing of the ukm 290 with The ANSI-X9.63-KDF key derivation function is described in 291 Section 2.1, and the processing of the ukm with the HKDF key 292 derivation function is described in Section 2.2. 294 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 295 identifier of the key-encryption algorithm that will be used to wrap 296 the content-encryption key. The conventions for using AES-128, 297 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 299 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 300 identifier and encrypted key for one or more recipients. The 301 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 302 the issuerAndSerialNumber identifying the recipient's certificate or 303 the RecipientKeyIdentifier containing the subject key identifier from 304 the recipient's certificate. In both cases, the recipient's 305 certificate contains the recipient's static X25519 or X448 public 306 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 307 encryption key encrypted with the pairwise key-encryption key using 308 the algorithm specified by the KeyWrapAlgorithm. 310 4. Authenticated-data Conventions 312 The CMS authenticated-data content type [CMS] consists an 313 authenticated content, a message authentication code (MAC), and 314 encrypted authentication keys for one or more recipients. The ECDH 315 key agreement algorithm is used to generate a pairwise key-encryption 316 key between the originator and a particular recipient. Then, the 317 key-encryption key is used to wrap the authentication key for that 318 recipient. When there is more than one recipient, the same 319 authentication key MUST be wrapped for each of them. 321 A compliant implementation MUST meet the requirements for 322 constructing an authenticated-data content type in Section 9 of 323 [CMS]. 325 A authentication key MUST be randomly generated for each instance of 326 an authenticated-data content type. The authentication key is used 327 to compute the MAC over the content. 329 4.1. AuthenticatedData Fields 331 The authenticated-data content type is ASN.1 encoded using the 332 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 333 MUST be populated as described in [CMS]; for the recipients that use 334 X25519 or X448 the RecipientInfo kari choice MUST be used. 336 4.2. KeyAgreeRecipientInfo Fields 338 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 339 described in Section 3.2 of this document. 341 5. Authenticated-Enveloped-data Conventions 343 The CMS authenticated-enveloped-data content type [AUTHENV] consists 344 of an authenticated and encrypted content and encrypted content- 345 authenticated-encryption keys for one or more recipients. The ECDH 346 key agreement algorithm is used to generate a pairwise key-encryption 347 key between the originator and a particular recipient. Then, the 348 key-encryption key is used to wrap the content-authenticated- 349 encryption key for that recipient. When there is more than one 350 recipient, the same content-authenticated-encryption key MUST be 351 wrapped for each of them. 353 A compliant implementation MUST meet the requirements for 354 constructing an authenticated-data content type in Section 2 of 355 [AUTHENV]. 357 A content-authenticated-encryption key MUST be randomly generated for 358 each instance of an authenticated-enveloped-data content type. The 359 content-authenticated-encryption key is used to authenticate and 360 encrypt the content. 362 5.1. AuthEnvelopedData Fields 364 The authenticated-enveloped-data content type is ASN.1 encoded using 365 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 366 syntax MUST be populated as described in [AUTHENV]; for the 367 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 368 be used. 370 5.2. KeyAgreeRecipientInfo Fields 372 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 373 described in Section 3.2 of this document. 375 6. Certificate Conventions 377 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 378 in Internet applications. A recipient static public key is needed 379 for X25519 or X448, and the originator obtains that public key from 380 the recipient's certificate. The conventions for carrying X25519 and 381 X448 public keys are specified in [ID.curdle-pkix]. 383 7. Key Agreement Algorithm Identifiers 385 The following object identifiers are assigned in [CMSECC] to indicate 386 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 387 are expected to be used as AlgorithmIdentifiers with a parameter that 388 specifies the key-encryption algorithm. These are repeated here for 389 convenience. 391 secg-scheme OBJECT IDENTIFIER ::= { 392 iso(1) identified-organization(3) certicom(132) schemes(1) } 394 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 395 secg-scheme 11 1 } 397 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 398 secg-scheme 11 2 } 400 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 401 secg-scheme 11 3 } 403 The following object identifiers are assigned to indicate ECDH with 404 HKDF using various one-way hash functions. These are expected to be 405 used as AlgorithmIdentifiers with a parameter that specifies the 406 key-encryption algorithm. 408 smime-alg OBJECT IDENTIFIER ::= { 409 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 410 pkcs-9(9) smime(16) alg(3) } 412 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 413 smime-alg 19 } 415 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 416 smime-alg 20 } 418 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 419 smime-alg 21 } 421 8. SMIMECapabilities Attribute Conventions 423 A sending agent MAY announce to other agents that it supports ECDH 424 key agreement using the SMIMECapabilities signed attribute in a 425 signed message [SMIME] or a certificate [CERTCAP]. Following the 426 pattern established in [CMSECC], the SMIMECapabilities associated 427 with ECDH carries a DER-encoded object identifier that identifies 428 support for ECDH in conjunction with a particular KDF, and it 429 includes a parameter that names the key wrap algorithm. 431 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 432 might be of interest to implementations that support X25519 and X448: 434 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 435 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 436 01 05 438 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 439 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 440 01 05 442 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 443 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 444 01 05 446 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 447 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 448 01 2D 450 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 451 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 452 01 2D 454 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 455 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 456 01 2D 458 The following SMIMECapabilities values (in hexidecimal) based on the 459 algorithm identifiers in Section 7 of this document might be of 460 interest to implementations that support X25519 and X448: 462 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 463 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 464 48 01 65 03 04 01 05 466 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 467 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 468 48 01 65 03 04 01 05 470 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 471 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 472 48 01 65 03 04 01 05 474 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 475 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86 476 48 01 65 03 04 01 2D 478 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 479 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86 480 48 01 65 03 04 01 2D 482 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 483 30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86 484 48 01 65 03 04 01 2D 486 9. Security Considerations 488 Please consult the security considerations of [CMS] for security 489 considerations related to the enveloped-data content type and the 490 authenticated-data content type. 492 Please consult the security considerations of [AUTHENV] for security 493 considerations related to the authenticated-enveloped-data content 494 type. 496 Please consult the security considerations of [CURVES] for security 497 considerations related to the use of X25519 and X448. 499 The originator uses an ephemeral public/private key pair that is 500 generated on the same elliptic curve as the public key of the 501 recipient. The ephemeral key pair is used for a single CMS protected 502 content type, and then it is discarded. If the originator wants to 503 be able to decrypt the content (for enveloped-data and authenticated- 504 enveloped-data) or check the authentication (for authenticated-data), 505 then the originator needs to treat themselves as a recipient. 507 As specified in [CMS], implementations MUST support processing of the 508 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 509 is not a concern whether the ukm is present or absent. The ukm is 510 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 511 When present, the ukm ensures that a different key-encryption key is 512 generated, even when the originator ephemeral private key is 513 improperly used more than once. 515 10. IANA Considerations 517 One object identifier for the ASN.1 module in the Appendix was 518 assigned in the SMI Security for S/MIME Module Identifiers 519 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 521 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 522 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 523 pkcs-9(9) smime(16) mod(0) 67 } 525 Three object identifiers for the Key Agreement Algorithm Identifiers 526 in Sections 7 were assigned in the SMI Security for S/MIME Algorithms 527 (1.2.840.113549.1.9.16.3) [IANA-ALG] registry: 529 smime-alg OBJECT IDENTIFIER ::= { 530 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 531 pkcs-9(9) smime(16) alg(3) } 533 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 534 smime-alg 19 } 536 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 537 smime-alg 20 } 539 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 540 smime-alg 21 } 542 11. Normative References 544 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 545 Authenticated-Enveloped-Data Content Type", RFC 5083, 546 November 2007. 548 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 549 Secure/Multipurpose Internet Mail Extensions (S/MIME) 550 Capabilities", RFC 4262, December 2005. 552 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 553 5652, September 2009. 555 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 556 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 557 June 2010. 559 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 560 Cryptography (ECC) Algorithms in Cryptographic Message 561 Syntax (CMS)", RFC 5753, January 2010. 563 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 564 for Security", RFC 7748, January 2016. 566 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 567 Expand Key Derivation Function (HKDF)", RFC 5869, May 568 2010. 570 [ID.curdle-pkix] 571 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 572 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 573 use in the Internet X.509 Public Key Infrastructure", 574 15 August 2016, Work-in-progress. 576 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 577 Identifiers for the Internet X.509 Public Key 578 Infrastructure Certificate and Certificate Revocation List 579 (CRL) Profile", RFC 3279, April 2002. 581 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 582 Housley, R., and W. Polk, "Internet X.509 Public Key 583 Infrastructure Certificate and Certificate Revocation List 584 (CRL) Profile", RFC 5280, May 2008. 586 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 587 Elliptic Curve Cryptography", version 2.0, May 2009, 588 . 590 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 591 Mail Extensions (S/MIME) Version 3.2 Message 592 Specification", RFC 5751, January 2010. 594 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 598 One (ASN.1): Specification of basic notation", ITU-T 599 Recommendation X.680, 2015. 601 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 602 Specification of Basic Encoding Rules (BER), Canonical 603 Encoding Rules (CER) and Distinguished Encoding Rules 604 (DER)", ITU-T Recommendation X.690, 2015. 606 12. Informative References 608 [AES] National Institute of Standards and Technology. FIPS Pub 609 197: Advanced Encryption Standard (AES). 26 November 2001. 611 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 612 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 614 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 615 Encryption Algorithm in Cryptographic Message Syntax 616 (CMS)", RFC 3565, July 2003. 618 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 619 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 620 Nov. 1976, pp. 644-654. 622 [IANA-ALG] https://www.iana.org/assignments/smi-numbers/ 623 smi-numbers.xhtml#security-smime-3. 625 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/ 626 smi-numbers.xhtml#security-smime-0. 628 [X963] "Public-Key Cryptography for the Financial Services 629 Industry: Key Agreement and Key Transport Using Elliptic 630 Curve Cryptography", American National Standard 631 X9.63-2001, 2001. 633 Appendix: ASN.1 Module 635 CMSECDHAlgs-2017 636 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 637 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(67) } 639 DEFINITIONS IMPLICIT TAGS ::= 640 BEGIN 642 -- EXPORTS ALL 644 IMPORTS 646 KeyWrapAlgorithm 647 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 648 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 649 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 651 KEY-AGREE, SMIME-CAPS 652 FROM AlgorithmInformation-2009 -- in [CMSASN1] 653 { iso(1) identified-organization(3) dod(6) internet(1) 654 security(5) mechanisms(5) pkix(7) id-mod(0) 655 id-mod-algorithmInformation-02(58) } 657 dhSinglePass-stdDH-sha256kdf-scheme, 658 dhSinglePass-stdDH-sha384kdf-scheme, 659 dhSinglePass-stdDH-sha512kdf-scheme, 660 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 661 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 662 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 663 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 664 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 665 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 666 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 667 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 668 pkcs-9(9) smime(16) modules(0) 669 id-mod-cms-ecc-alg-2009-02(46) } 670 ; 672 -- 673 -- Object Identifiers 674 -- 676 smime-alg OBJECT IDENTIFIER ::= { 677 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 678 pkcs-9(9) smime(16) alg(3) } 680 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 681 smime-alg 19 } 683 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 684 smime-alg 20 } 686 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 687 smime-alg 21 } 689 -- 690 -- Extend the Key Agreement Algorithms in [CMSECC] 691 -- 693 KeyAgreementAlgs KEY-AGREE ::= { ..., 694 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 695 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 696 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 697 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 698 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 699 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 701 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 702 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 703 PARAMS TYPE KeyWrapAlgorithm ARE required 704 UKM -- TYPE unencoded data -- ARE preferredPresent 705 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 707 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 708 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 709 PARAMS TYPE KeyWrapAlgorithm ARE required 710 UKM -- TYPE unencoded data -- ARE preferredPresent 711 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 713 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 714 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 715 PARAMS TYPE KeyWrapAlgorithm ARE required 716 UKM -- TYPE unencoded data -- ARE preferredPresent 717 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 719 -- 720 -- Extend the S/MIME CAPS in [CMSECC] 721 -- 723 SMimeCAPS SMIME-CAPS ::= { ..., 724 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 725 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 726 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 727 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 728 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 729 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 731 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 732 TYPE KeyWrapAlgorithm 733 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 735 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 736 TYPE KeyWrapAlgorithm 737 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 739 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 740 TYPE KeyWrapAlgorithm 741 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 743 END 745 Acknowledgements 747 Many thanks to Roni Even, Daniel Migault, Eric Rescorla, Jim Schaad, 748 Stefan Santesson, and Sean Turner for their review and insightful 749 suggestions. 751 Author's Address 753 Russ Housley 754 918 Spring Knoll Drive 755 Herndon, VA 20170 756 USA 757 housley@vigilsec.com