idnits 2.17.1 draft-ietf-curdle-cms-ecdh-new-curves-02.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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (27 March 2017) is 2587 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) == Missing Reference: 'CURVE' is mentioned on line 105, but not defined -- Looks like a reference, but probably isn't: '0' on line 117 -- Looks like a reference, but probably isn't: '2' on line 118 ** Downref: Normative reference to an Informational RFC: RFC 5911 (ref. 'CMSASN1') ** Downref: Normative reference to an Informational RFC: RFC 5753 (ref. 'CMSECC') ** Downref: Normative reference to an Informational RFC: RFC 7748 (ref. 'CURVES') ** Downref: Normative reference to an Informational RFC: RFC 5869 (ref. 'HKDF') -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.curdle-pkix' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' ** Obsolete normative reference: RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 27 September 2017 27 March 2017 6 Use of the Elliptic Curve Diffie-Hellamn 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-Hellamn (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 27 September 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-Hellamn (ECDH) key agreement using curve25519 and curve448 53 [CURVE] 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 [CURVE]. 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 describe a means for two parties to agree 83 upon a shared secret value in manner that prevents eavesdroppers from 84 learning the shared secret value [DH1976]. This secret may then be 85 converted into pairwise symmetric keying material for use with other 86 cryptographic algorithms. Over the years, many variants of this 87 fundamental technique have been developed. This document describes 88 the conventions for using Ephemeral-Static Elliptic Curve Diffie- 89 Hellamn (ECDH) key agreement using X25519 and X448 [CURVE]. 91 The originator uses an ephemeral public/private key pair that is 92 generated on the same elliptic curve as the public key of the 93 recipient. The ephemeral key pair is used for a single CMS protected 94 content type, and then it is discarded. The originator obtains the 95 recipient's static public key from the recipient's certificate 96 [PROFILE]. 98 X25519 is described in Section 6.1 of [CURVE], and X448 is described 99 in Section 6.2 of [CURVE]. Since curve25519 and curve448 have 100 cofactors of 8 and 4, respectively, an input point of small order 101 will eliminate any contribution from the other party's private key. 102 As described in Section 7 of [CURVE], implementations MAY detect this 103 situation by checking for the all-zero output. 105 In [CURVE], 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 from the shared secret value (K), the 109 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. The ukm value need not 131 be longer than the key-encryption key that will be produced by the 132 KDF. When present, the ukm ensures that a different key-encryption 133 key is generated, even when the originator ephemeral private key is 134 improperly used more than once. 136 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 137 generated key-encryption key, in bits, represented as a 32-bit 138 number. For example, the key length for AES-256 [AES] would be 139 0x00000100. 141 2.1. ANSI-X9.63-KDF 143 The ANSI-X9.63-KDF key derivation function is a simple construct 144 based on a one-way hash function described in ANS X9.63 [X963]. This 145 KDF is also described in Section 3.6.1 of [SEC1]. 147 Three values are concatenated to produce the input string to the KDF: 148 1. The shared secret value generated by ECDH, K. 149 2. The iteration counter, starting with one, as described below. 150 3. The DER-encoded ECC-CMS-SharedInfo structure. 152 To generate a key-encryption key, generates one or more KM blocks, 153 with the counter starting at 0x00000001, and incrementing the counter 154 for each subsequent KM block until enough material has been 155 generated. The KM blocks are concatenated left to right to produce 156 the pairwise key-encryption key, KEK: 158 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 160 KEK = KM(counter=1) || KM(counter=2) ... 162 2.2. HKDF 164 The HKDF key derivation function is a robust construct based on a 165 one-way hash function described in RFC 5869 [HKDF]. HKDF is 166 comprised of two steps: HKDF-Extract followed by HKDF-Expand. 168 Three values are used as inputs to the HKDF: 169 1. The shared secret value generated by ECDH, K. 170 2. The length in octets of the keying data to be generated. 171 3. The DER-encoded ECC-CMS-SharedInfo structure. 173 The ECC-CMS-SharedInfo structure optionally includes the ukm. If the 174 ukm is present, the ukm is also used as the HKDF salt. 176 The length of the generated key-encryption key is used two places, 177 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 178 includes the length of the generated key-encryption key in bits. The 179 HKDF-Expand function takes an argument for the length of the 180 generated key-encryption key in octets. 182 In summary, to produce the pairwise key-encryption key, KEK: 184 if ukm is provided, then salt = ukm, else salt = zero 185 PRK = HKDF-Extract(salt, K) 187 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 189 3. Enveloped-data Conventions 191 The CMS enveloped-data content type [CMS] consists of an encrypted 192 content and wrapped content-encryption keys for one or more 193 recipients. The ECDH key agreement algorithm is used to generate a 194 pairwise key-encryption key between the originator and a particular 195 recipient. Then, the key-encryption key is used to wrap the content- 196 encryption key for that recipient. When there is more than one 197 recipient, the same content-encryption key MUST be wrapped for each 198 of them. 200 A compliant implementation MUST meet the requirements for 201 constructing an enveloped-data content type in Section 6 of [CMS]. 203 A content-encryption key MUST be randomly generated for each instance 204 of an enveloped-data content type. The content-encryption key is 205 used to encrypt the content. 207 3.1. EnvelopedData Fields 209 The enveloped-data content type is ASN.1 encoded using the 210 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 211 populated as described in [CMS]; for the recipients that use X25519 212 or X448 the RecipientInfo kari choice MUST be used. 214 3.2. KeyAgreeRecipientInfo Fields 216 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 217 described in this section when X25519 or X448 is employed for one or 218 more recipients. 220 The KeyAgreeRecipientInfo version MUST be 3. 222 The KeyAgreeRecipientInfo originator provides three alternatives for 223 identifying the originator's public key, and the originatorKey 224 alternative MUST be used. The originatorKey MUST contain an 225 ephemeral key for the originator. The originatorKey algorithm field 226 MUST contain the id-ecPublicKey object identifier along with 227 ECParameters as specified in [PKIXECC]. The originator's ephemeral 228 public key MUST be encoded using the type ECPoint as specified in 229 [CMSECC]. As a convenience, the definitions are repeated here: 231 id-ecPublicKey OBJECT IDENTIFIER ::= { 232 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 234 ECPoint ::= OCTET STRING 236 ECParameters ::= CHOICE { 237 namedCurve OBJECT IDENTIFIER 238 -- implicitCurve NULL -- 239 -- specifiedCurve SpecifiedECDomain -- } 241 The object identifiers for X25519 and X448 have been assigned in 242 [ID.curdle-pkix]. They are repeated below for convenience. 244 When using X25519, the ECPoint contains exactly 32 octets, and the 245 ECParameters namedCurve MUST contain the following object identifier: 247 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 249 When using X448, the ECPoint contains exactly 56 octets, and the 250 ECParameters namedCurve MUST contain the following object identifier: 252 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 254 KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires 255 implementations to accept a KeyAgreeRecipientInfo SEQUENCE that 256 includes the ukm field. If present, the ukm is placed in the 257 entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The 258 ukm value need not be longer than the key-encryption key produced by 259 the KDF. 261 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 262 identifier of the key-encryption algorithm that will be used to wrap 263 the content-encryption key. The conventions for using AES-128, 264 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 266 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 267 identifier and encrypted key for one or more recipients. The 268 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 269 the issuerAndSerialNumber identifying the recipient's certificate or 270 the RecipientKeyIdentifier containing the subject key identifier from 271 the recipient's certificate. In both cases, the recipient's 272 certificate contains the recipient's static X25519 or X448 public 273 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 274 encryption key encrypted with the pairwise key-encryption key using 275 the algorithm specified by the KeyWrapAlgorithm. 277 4. Authenticated-data Conventions 279 The CMS authenticated-data content type [CMS] consists an 280 authenticated content, a message authentication code (MAC), and 281 encrypted authentication keys for one or more recipients. The ECDH 282 key agreement algorithm is used to generate a pairwise key-encryption 283 key between the originator and a particular recipient. Then, the 284 key-encryption key is used to wrap the authentication key for that 285 recipient. When there is more than one recipient, the same 286 authentication key MUST be wrapped for each of them. 288 A compliant implementation MUST meet the requirements for 289 constructing an authenticated-data content type in Section 9 of 290 [CMS]. 292 A authentication key MUST be randomly generated for each instance of 293 an authenticated-data content type. The authentication key is used 294 to compute the MAC over the content. 296 4.1. AuthenticatedData Fields 298 The authenticated-data content type is ASN.1 encoded using the 299 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 300 MUST be populated as described in [CMS]; for the recipients that use 301 X25519 or X448 the RecipientInfo kari choice MUST be used. 303 4.2. KeyAgreeRecipientInfo Fields 305 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 306 described in Section 3.2 of this document. 308 5. Authenticated-Enveloped-data Conventions 310 The CMS authenticated-enveloped-data content type [AUTHENV] consists 311 of an authenticated and encrypted content and encrypted content- 312 authenticated-encryption keys for one or more recipients. The ECDH 313 key agreement algorithm is used to generate a pairwise key-encryption 314 key between the originator and a particular recipient. Then, the 315 key-encryption key is used to wrap the content-authenticated- 316 encryption key for that recipient. When there is more than one 317 recipient, the same content-authenticated-encryption key MUST be 318 wrapped for each of them. 320 A compliant implementation MUST meet the requirements for 321 constructing an authenticated-data content type in Section 2 of 322 [AUTHENV]. 324 A content-authenticated-encryption key MUST be randomly generated for 325 each instance of an authenticated-enveloped-data content type. The 326 content-authenticated-encryption key key is used to authenticate and 327 encrypt the content. 329 5.1. AuthEnvelopedData Fields 331 The authenticated-enveloped-data content type is ASN.1 encoded using 332 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 333 syntax MUST be populated as described in [AUTHENV]; for the 334 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 335 be used. 337 5.2. KeyAgreeRecipientInfo Fields 339 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 340 described in Section 3.2 of this document. 342 6. Certificate Conventions 344 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 345 in Internet applications. A recipient static public key is needed 346 for X25519 or X448, and the originator obtains that public key from 347 the recipient's certificate. The conventions in this section augment 348 RFC 5280 [PROFILE]. 350 The id-ecPublicKey object identifier continues to identify the static 351 ECDH public key for the recipient. The associated EcpkParameters 352 parameters structure is specified in [PKIXALG], and the namedCurve 353 alternative MUST be used. The object identifiers from Section 3.2 of 354 this document are used for X25519 and X448. The EcpkParameters 355 parameters structure is repeated here for convenience: 357 EcpkParameters ::= CHOICE { 358 ecParameters ECParameters, 359 namedCurve OBJECT IDENTIFIER, 360 implicitlyCA NULL } 362 The certificate issuer MAY indicate the intended usage for the 363 certified public key by including the key usage certificate extension 364 as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage 365 extension is present in a certificate that conveys an ECDH static 366 public key, then the key usage extension MUST set the keyAgreement 367 bit. 369 7. Key Agreement Algorithm Identifiers 371 The following object identifiers are assigned in [CMSECC] to indicate 372 ECDH with ANSI-X9.63-KDF using various one-way hash functions. These 373 are expected to be used as AlgorithmIdentifiers with a parameter that 374 specifies the key-encryption algorithm. These are repeated here for 375 convenience. 377 secg-scheme OBJECT IDENTIFIER ::= { 378 iso(1) identified-organization(3) certicom(132) schemes(1) } 380 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 381 secg-scheme 11 1 } 383 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 384 secg-scheme 11 2 } 386 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 387 secg-scheme 11 3 } 389 The following object identifiers are assigned to indicate ECDH with 390 HKDF using various one-way hash functions. These are expected to be 391 used as AlgorithmIdentifiers with a parameter that specifies the 392 key-encryption algorithm. 394 smime-alg OBJECT IDENTIFIER ::= { 395 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 396 pkcs-9(9) smime(16) alg(3) } 398 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 399 smime-alg TBD1 } 401 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 402 smime-alg TBD2 } 404 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 405 smime-alg TBD3 } 407 8. SMIMECapabilities Attribute Conventions 409 A sending agent MAY announce to other agents that it supports ECDH 410 key agreement using the SMIMECapabilities signed attribute in a 411 signed message [SMIME] or a certificate [CERTCAP]. Following the 412 pattern established in [CMSECC], the SMIMECapabilities associated 413 with ECDH carries a DER-encoded object identifier that identifies 414 support for ECDH in conjunction with a particular KDF, and it 415 includes a parameter that names the key wrap algorithm. 417 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 418 might be of interest to implementations that support X25519 and X448: 420 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 421 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 422 01 05 424 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 425 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 426 01 05 428 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 429 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 430 01 05 432 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 433 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 434 01 2D 436 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 437 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 438 01 2D 440 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 441 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 442 01 2D 444 The following SMIMECapabilities values (in hexidecimal) based on the 445 algorithm identifiers in Section 7 of this document might be of 446 interest to implementations that support X25519 and X448: 448 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 449 TBD 451 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 452 TBD 454 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 455 TBD 457 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 458 TBD 460 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 461 TBD 463 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 464 TBD 466 9. Security Considerations 468 Please consult the security considerations of [CMS] for security 469 considerations related to the enveloped-data content type and the 470 authenticated-data content type. 472 Please consult the security considerations of [AUTHENV] for security 473 considerations related to the authenticated-enveloped-data content 474 type. 476 Please consult the security considerations of [CURVES] for security 477 considerations related to the use of X25519 and X448. 479 The originator uses an ephemeral public/private key pair that is 480 generated on the same elliptic curve as the public key of the 481 recipient. The ephemeral key pair is used for a single CMS protected 482 content type, and then it is discarded. If the originator wants to 483 be able to decrypt the content (for enveloped-data and authenticated- 484 enveloped-data) or check the authentication (for authenticated-data), 485 then the originator needs to treat themselves as a recipient. 487 As specified in [CMS], implementations MUST support processing of the 488 KeyAgreeRecipientInfo ukm field; this ensures that interoperability 489 is not a concern whether the ukm is present or absent. The ukm is 490 placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. 491 When present, the ukm ensures that a different key-encryption key is 492 generated, even when the originator ephemeral private key is 493 improperly used more than once. 495 10. IANA Considerations 497 One object identifier for the ASN.1 module in the Appendix needs to 498 be assigned in the SMI Security for S/MIME Module Identifiers 499 (1.2.840.113549.1.9.16.0) registry: 501 id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= { 502 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 503 pkcs-9(9) smime(16) mod(0) TBD0 } 505 Three object identifiers for the Key Agreement Algorithm Identifiers 506 in Sections 7 need to be assigned in the SMI Security for S/MIME 507 Algorithms (1.2.840.113549.1.9.16.3) registry: 509 smime-alg OBJECT IDENTIFIER ::= { 510 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 511 pkcs-9(9) smime(16) alg(3) } 513 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 514 smime-alg TBD1 } 516 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 517 smime-alg TBD2 } 519 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 520 smime-alg TBD3 } 522 11. Normative References 524 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 525 Authenticated-Enveloped-Data Content Type", RFC 5083, 526 November 2007. 528 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 529 Secure/Multipurpose Internet Mail Extensions (S/MIME) 530 Capabilities", RFC 4262, December 2005. 532 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 533 5652, September 2009. 535 [CMSASN1] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 536 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 537 June 2010. 539 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 540 Cryptography (ECC) Algorithms in Cryptographic Message 541 Syntax (CMS)", RFC 5753, January 2010. 543 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 544 for Security", RFC 7748, January 2016. 546 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 547 Expand Key Derivation Function (HKDF)", RFC 5869, May 548 2010. 550 [ID.curdle-pkix] 551 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 552 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 553 use in the Internet X.509 Public Key Infrastructure", 554 15 August 2016, Work-in-progress. 556 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 557 Identifiers for the Internet X.509 Public Key 558 Infrastructure Certificate and Certificate Revocation List 559 (CRL) Profile", RFC 3279, April 2002. 561 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 562 "Elliptic Curve Cryptography Subject Public Key 563 Information", RFC 5480, March 2009. 565 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 566 Housley, R., and W. Polk, "Internet X.509 Public Key 567 Infrastructure Certificate and Certificate Revocation List 568 (CRL) Profile", RFC 5280, May 2008. 570 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 571 Elliptic Curve Cryptography", version 2.0, May 2009, 572 . 574 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 575 Mail Extensions (S/MIME) Version 3.2 Message 576 Specification", RFC 5751, January 2010. 578 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 582 One (ASN.1): Specification of basic notation", ITU-T 583 Recommendation X.680, 2015. 585 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 586 Specification of Basic Encoding Rules (BER), Canonical 587 Encoding Rules (CER) and Distinguished Encoding Rules 588 (DER)", ITU-T Recommendation X.690, 2015. 590 12. Informative References 592 [AES] National Institute of Standards and Technology. FIPS Pub 593 197: Advanced Encryption Standard (AES). 26 November 2001. 595 [AESKW] Schaad, J., and R. Housley, "Advanced Encryption Standard 596 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 598 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 599 Encryption Algorithm in Cryptographic Message Syntax 600 (CMS)", RFC 3565, July 2003. 602 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 603 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 604 Nov. 1976, pp. 644-654. 606 [X963] "Public-Key Cryptography for the Financial Services 607 Industry: Key Agreement and Key Transport Using Elliptic 608 Curve Cryptography", American National Standard 609 X9.63-2001, 2001. 611 Appendix: ASN.1 Module 613 CMSECDHAlgs-2017 614 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 615 smime(16) modules(0) id-mod-cms-ecdh-alg-2017(TBD0) } 617 DEFINITIONS IMPLICIT TAGS ::= 618 BEGIN 620 -- EXPORTS ALL 622 IMPORTS 624 KeyWrapAlgorithm 625 FROM CryptographicMessageSyntaxAlgorithms-2009 -- in [CMSASN1] 626 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 627 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) } 629 KEY-AGREE, SMIME-CAPS 630 FROM AlgorithmInformation-2009 -- in [CMSASN1] 631 { iso(1) identified-organization(3) dod(6) internet(1) 632 security(5) mechanisms(5) pkix(7) id-mod(0) 633 id-mod-algorithmInformation-02(58) } 635 dhSinglePass-stdDH-sha256kdf-scheme, 636 dhSinglePass-stdDH-sha384kdf-scheme, 637 dhSinglePass-stdDH-sha512kdf-scheme, 638 kaa-dhSinglePass-stdDH-sha256kdf-scheme, 639 kaa-dhSinglePass-stdDH-sha384kdf-scheme, 640 kaa-dhSinglePass-stdDH-sha512kdf-scheme, 641 cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme, 642 cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme, 643 cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme 644 FROM CMSECCAlgs-2009-02 -- in [CMSECC] 645 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 646 pkcs-9(9) smime(16) modules(0) 647 id-mod-cms-ecc-alg-2009-02(46) } ; 649 -- 650 -- Object Identifiers 651 -- 653 smime-alg OBJECT IDENTIFIER ::= { 654 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 655 pkcs-9(9) smime(16) alg(3) } 657 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 658 smime-alg TBD1 } 660 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 661 smime-alg TBD2 } 663 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 664 smime-alg TBD3 } 666 -- 667 -- Extend the Key Agreement Algorithms in [CMSECC] 668 -- 670 KeyAgreementAlgs KEY-AGREE ::= { ..., 671 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 672 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 673 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 674 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme | 675 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme | 676 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 678 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= { 679 IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme 680 PARAMS TYPE KeyWrapAlgorithm ARE required 681 UKM -- TYPE unencoded data -- ARE preferredPresent 682 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme } 684 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= { 685 IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme 686 PARAMS TYPE KeyWrapAlgorithm ARE required 687 UKM -- TYPE unencoded data -- ARE preferredPresent 688 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme } 690 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= { 691 IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme 692 PARAMS TYPE KeyWrapAlgorithm ARE required 693 UKM -- TYPE unencoded data -- ARE preferredPresent 694 SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme } 696 -- 697 -- Extend the S/MIME CAPS in [CMSECC] 698 -- 700 SMimeCAPS SMIME-CAPS ::= { ..., 701 kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps | 702 kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps | 703 kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps | 704 kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps | 705 kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps | 706 kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps } 708 cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= { 709 TYPE KeyWrapAlgorithm 710 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme } 712 cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= { 713 TYPE KeyWrapAlgorithm 714 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme} 716 cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= { 717 TYPE KeyWrapAlgorithm 718 IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme } 720 END 722 Acknowledgements 724 Many thanks to Jim Schaad, Stefan Santesson, Sean Turner for their 725 review and insightful suggestions. 727 Author Address 729 Russ Housley 730 918 Spring Knoll Drive 731 Herndon, VA 20170 732 USA 733 housley@vigilsec.com