idnits 2.17.1 draft-ietf-lamps-cms-mix-with-psk-01.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 (19 November 2018) is 1984 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: 'RFC5803' is mentioned on line 85, but not defined == Missing Reference: 'RFC4055' is mentioned on line 103, but not defined -- Looks like a reference, but probably isn't: '0' on line 505 -- Looks like a reference, but probably isn't: '1' on line 506 == Unused Reference: 'RFC3560' is defined on line 687, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Proposed Standard Vigil Security 4 Expires: 19 May 2019 19 November 2018 6 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) 7 9 Abstract 11 The invention of a large-scale quantum computer would pose a serious 12 challenge for the cryptographic algorithms that are widely deployed 13 today. The Cryptographic Message Syntax (CMS) supports key transport 14 and key agreement algorithms that could be broken by the invention of 15 such a quantum computer. By storing communications that are 16 protected with the CMS today, someone could decrypt them in the 17 future when a large-scale quantum computer becomes available. Once 18 quantum-secure key management algorithms are available, the CMS will 19 be extended to support the new algorithms, if the existing syntax 20 does not accommodate them. In the near-term, this document describes 21 a mechanism to protect today's communication from the future 22 invention of a large-scale quantum computer by mixing the output of 23 key transport and key agreement algorithms with a pre-shared key. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5 63 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 64 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 10.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 The invention of a large-scale quantum computer would pose a serious 78 challenge for the cryptographic algorithms that are widely deployed 79 today. It is an open question whether or not it is feasible to build 80 a large-scale quantum computer, and if so, when that might happen. 81 However, if such a quantum computer is invented, many of the 82 cryptographic algorithms and the security protocols that use them 83 would become vulnerable. 85 The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] supports 86 key transport and key agreement algorithms that could be broken by 87 the invention of a large-scale quantum computer [C2PQ]. These 88 algorithms include RSA [RFC4055], Diffie-Hellman [RFC2631], and 89 Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary 90 that stores CMS-protected communications today, could decrypt those 91 communications in the future when a large-scale quantum computer 92 becomes available. 94 Once quantum-secure key management algorithms are available, the CMS 95 will be extended to support them, if the existing syntax does not 96 already accommodate the new algorithms. 98 In the near-term, this document describes a mechanism to protect 99 today's communication from the future invention of a large-scale 100 quantum computer by mixing the output of existing key transport and 101 key agreement algorithms with a pre-shared key (PSK). Secure 102 communication can be achieved today by mixing a strong PSK with the 103 output of an existing key transport algorithm, like RSA [RFC4055], or 104 an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or 105 Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is 106 believed to be quantum resistant can be achieved by using a PSK with 107 sufficient entropy along with a quantum resistant key derivation 108 function (KDF), like HKDF [RFC5869], and a quantum resistant 109 encryption algorithm, like 256-bit AES [AES]. In this way, today's 110 CMS-protected communication can be invulnerable to an attacker with a 111 large-scale quantum computer. 113 Note that the CMS also supports key management techniques based on 114 symmetric key-encryption keys and passwords, but they are not 115 discussed in this document because they are already quantum 116 resistant. The symmetric key-encryption key technique is quantum 117 resistant when used with an adequate key size. The password 118 technique is quantum resistant when used with a quantum-resistant key 119 derivation function and a sufficiently large password. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 1.2. ASN.1 131 CMS values are generated using ASN.1 [X680], which uses the Basic 132 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 133 [X690]. 135 1.3. Version Numbers 137 The major data structures include a version number as the first item 138 in the data structure. The version number is intended to avoid ASN.1 139 decode errors. Some implementations do not check the version number 140 prior to attempting a decode, and then if a decode error occurs, the 141 version number is checked as part of the error handling routine. 143 This is a reasonable approach; it places error processing outside of 144 the fast path. This approach is also forgiving when an incorrect 145 version number is used by the sender. 147 Whenever the structure is updated, a higher version number will be 148 assigned. However, to ensure maximum interoperability, the higher 149 version number is only used when the new syntax feature is employed. 150 That is, the lowest version number that supports the generated syntax 151 is used. 153 2. Overview 155 The CMS enveloped-data content type [RFC5652] and the CMS 156 authenticated-enveloped-data content type [RFC5083] support both key 157 transport and key agreement public-key algorithms to establish the 158 key used to encrypt the content. No restrictions are imposed on the 159 key transport or key agreement public-key algorithms, which means 160 that any key transport or key agreement algorithm can be used, 161 including algorithms that are specified in the future. In both 162 cases, the sender randomly generates the content-encryption key, and 163 then all recipients obtain that key. All recipients use the sender- 164 generated symmetric key for decryption. 166 This specification defines two quantum-resistant ways to establish a 167 symmetric key-derivation key. In both cases, the PSK is mixed with 168 the key-derivation key to create a quantum-resistant key-encryption 169 key. The PSK MUST be distributed to the sender and all of the 170 recipients by some out-of-band means that does not make it vulnerable 171 to the future invention of a large-scale quantum computer, and an 172 identifier MUST be assigned to the PSK. 174 The content-encryption key or content-authenticated-encryption key is 175 quantum-resistant, and it is established using these steps: 177 1. The content-encryption key or the content-authenticated-encryption 178 key is generated at random. 180 2. The key-derivation key is generated at random. 182 3. The key-encryption key is established for each recipient. The 183 details depend on the key management algorithm used: 185 key transport: the key-derivation key is encrypted in the 186 recipient's public key, then the key derivation function (KDF) 187 is used to mix the pre-shared key (PSK) and the key-derivation 188 key to produce the key-encryption key; or 190 key agreement: the recipient's public key and the sender's 191 private key are used to generate a pairwise symmetric key, then 192 the key derivation function (KDF) is used to mix the pre-shared 193 key (PSK) and the pairwise symmetric key to produce the key- 194 encryption key. 196 4. The key-encryption key is used to encrypt the content-encryption 197 key or content-authenticated-encryption key. 199 As specified in Section 6.2.5 of [RFC5652], recipient information for 200 additional key management techniques are represented in the 201 OtherRecipientInfo type. Two key management techniques are specified 202 in this document, and they are each identified by a unique ASN.1 203 object identifier. 205 The first key management technique, called keyTransPSK, see 206 Section 3, uses a key transport algorithm to transfer the key- 207 derivation key from the sender to the recipient, and then the key- 208 derivation key is mixed with the PSK using a KDF. The output of the 209 KDF is the key-encryption key for the encryption of the content- 210 encryption key or content-authenticated-encryption key. 212 The second key management technique, called keyAgreePSK, see 213 Section 4, uses a key agreement algorithm to establish a pairwise 214 key-encryption key, which is used to encrypt the key-derivation key, 215 and the then key-derivation key is mixed with the PSK using a KDF. 216 The output of the KDF is the key-encryption key for the encryption of 217 the content-encryption key or content-authenticated-encryption key. 219 3. KeyTransPSKRecipientInfo 221 Per-recipient information using keyTransPSK is represented in the 222 KeyTransPSKRecipientInfo type, which is indicated by the id-ori- 223 keyTransPSK object identifier. Each instance of 224 KeyTransPSKRecipientInfo establishes the content-encryption key or 225 content-authenticated-encryption key for one or more recipients that 226 have access to the same PSK. 228 The id-ori-keyTransPSK object identifier is: 230 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 231 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 233 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 235 The KeyTransPSKRecipientInfo type is: 237 KeyTransPSKRecipientInfo ::= SEQUENCE { 238 version CMSVersion, -- always set to 0 239 pskid PreSharedKeyIdentifier, 240 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 241 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 242 ktris KeyTransRecipientInfos, 243 encryptedKey EncryptedKey } 245 PreSharedKeyIdentifier ::= OCTET STRING 247 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 249 The fields of the KeyTransPSKRecipientInfo type have the following 250 meanings: 252 version is the syntax version number. The version MUST be 0. The 253 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 255 pskid is the identifier of the PSK used by the sender. The 256 identifier is an OCTET STRING, and it need not be human readable. 258 kdfAlgorithm identifies the key-derivation algorithm, and any 259 associated parameters, used by the sender to mix the key- 260 derivation key and the PSK to generate the key-encryption key. 261 The KeyDerivationAlgorithmIdentifier is described in Section 262 10.1.6 of [RFC5652]. 264 keyEncryptionAlgorithm identifies a key-encryption algorithm used 265 to encrypt the content-encryption key. The 266 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 267 [RFC5652]. 269 ktris contains one KeyTransRecipientInfo type for each recipient; 270 it uses a key transport algorithm to establish the key-derivation 271 key. KeyTransRecipientInfo is described in Section 6.2.1 of 272 [RFC5652]. 274 encryptedKey is the result of encrypting the content-encryption 275 key or the content-authenticated-encryption key with the key- 276 encryption key. EncryptedKey is an OCTET STRING. 278 4. KeyAgreePSKRecipientInfo 280 Per-recipient information using keyAgreePSK is represented in the 281 KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- 282 keyAgreePSK object identifier. Each instance of 283 KeyAgreePSKRecipientInfo establishes the content-encryption key or 284 content-authenticated-encryption key for one or more recipients that 285 have access to the same PSK. 287 The id-ori-keyAgreePSK object identifier is: 289 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 291 The KeyAgreePSKRecipientInfo type is: 293 KeyAgreePSKRecipientInfo ::= SEQUENCE { 294 version CMSVersion, -- always set to 0 295 pskid PreSharedKeyIdentifier, 296 originator [0] EXPLICIT OriginatorIdentifierOrKey, 297 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 298 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 299 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 300 recipientEncryptedKeys RecipientEncryptedKeys } 302 The fields of the KeyAgreePSKRecipientInfo type have the following 303 meanings: 305 version is the syntax version number. The version MUST be 0. The 306 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 308 pskid is the identifier of the PSK used by the sender. The 309 identifier is an OCTET STRING, and it need not be human readable. 311 originator is a CHOICE with three alternatives specifying the 312 sender's key agreement public key. Implementations MUST support 313 all three alternatives for specifying the sender's public key. 314 The sender uses their own private key and the recipient's public 315 key to generate a pairwise symmetric secret value. A key 316 derivation function (KDF) is used to mix the PSK and the pairwise 317 symmetric secret value to produce a key-encryption key. The 318 OriginatorIdentifierOrKey type is described in Section 6.2.2 of 319 [RFC5652]. 321 ukm is optional. With some key agreement algorithms, the sender 322 provides a User Keying Material (UKM) to ensure that a different 323 key is generated each time the same two parties generate a 324 pairwise key. Implementations MUST accept a 325 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 326 Implementations that do not support key agreement algorithms that 327 make use of UKMs MUST gracefully handle the presence of UKMs. The 328 UserKeyingMaterial type is described in Section 10.2.6 of 329 [RFC5652]. 331 kdfAlgorithm identifies the key-derivation algorithm, and any 332 associated parameters, used by the sender to mix the pairwise key 333 and the PSK. The pairwise key input to the key-derivation 334 algorithm MUST be the same length as the key-encryption key that 335 will be the output by the key-derivation algorithm. The 336 KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of 337 [RFC5652]. 339 keyEncryptionAlgorithm identifies a key-encryption algorithm used 340 to encrypt the content-encryption key or the content- 341 authenticated-encryption key. The 342 KeyEncryptionAlgorithmIdentifier type is described in Section 343 10.1.3 of [RFC5652]. 345 recipientEncryptedKeys includes a recipient identifier and 346 encrypted key for one or more recipients. The 347 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 348 specifying the recipient's certificate, and thereby the 349 recipient's public key, that was used by the sender to generate a 350 pairwise key. The encryptedKey is the result of encrypting the 351 content-encryption key or the content-authenticated-encryption key 352 with the key-encryption key. EncryptedKey is an OCTET STRING. 353 The RecipientEncryptedKeys type is defined in Section 6.2.2 of 354 [RFC5652]. 356 5. Key Derivation 358 Many key derivation functions (KDFs) internally employ a one-way hash 359 function. When this is the case, the hash function that is used is 360 identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] 361 is one example of a KDF that make use fo a hash function. 363 A KDF has several inout values. This section describes the 364 conventions for using the KDF to compute the key-encryption key for 365 KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For 366 simplicity, the terminology used in the HKDF [RFC5869] specification 367 is used here. 369 The KDF inputs are: 371 IKM is the input keying material; it is the symmetric secret input 372 to the KDF. For KeyTransPSKRecipientInfo, it is the PSK 373 concatenated with the key-derivation key. For 374 KeyAgreePSKRecipientInfo, it is the PSK concatenated with the 375 pairwise symmetric secret value produced by the key agreement 376 algorithm. 378 salt is an optional non-secret random value. The salt is not 379 used. 381 L is the length of output keying material in octets; the value 382 depends on the key-encryption algorithm that will be used. The 383 algorithm is identified by the KeyEncryptionAlgorithmIdentifier. 384 In addition, the OBJECT IDENTIFIER portion of the 385 KeyEncryptionAlgorithmIdentifier is included in the next input, 386 called info. 388 info is optional context and application specific information. 389 The DER-encoding of CMSORIforPSKOtherInfo is used as the info 390 value. Note that EXPLICIT tagging is used in the ASN.1 module 391 that deines this structure. For KeyTransPSKRecipientInfo, the 392 ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the 393 ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined 394 by the following ASN.1 structure: 396 CMSORIforPSKOtherInfo ::= SEQUENCE { 397 keyMgmtAlgType ENUMERATED { 398 keyTrans (5), 399 keyAgree (10) }, 400 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 401 pskLength INTEGER (1..MAX), 402 kdkLength INTEGER (1..MAX) } 404 The fields of type CMSORIforPSKOtherInfo have the following meanings: 406 keyMgmtAlgType is either set to 5 or 10. For 407 KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For 408 KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. 410 keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, 411 which identifies the algorithm and provides algorithm parameters, 412 if any. 414 pskLength is a positive integer; it contains the length of the PSK 415 in octets. 417 kdkLength is a positive integer; it contains the length of the 418 key-derivation key in octets. For KeyTransPSKRecipientInfo, the 419 key-derivation key is generated by the sender. For 420 KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise 421 symmetric key produced by the key agreement algorithm. 423 The KDF output is: 425 OKM is the output keying material, which is exactly L octets. The 426 OKM is the key-encryption key. 428 6. ASN.1 Module 430 This section contains the ASN.1 module for the two key management 431 techniques defined in this document. This module imports types from 432 other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. 434 CMSORIforPSK-2017 435 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 436 smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) } 438 DEFINITIONS EXPLICIT TAGS ::= 439 BEGIN 441 -- EXPORTS All 443 IMPORTS 445 AlgorithmIdentifier{}, KEY-DERIVATION 446 FROM AlgorithmInformation-2009 -- [RFC5912] 447 { iso(1) identified-organization(3) dod(6) internet(1) 448 security(5) mechanisms(5) pkix(7) id-mod(0) 449 id-mod-algorithmInformation-02(58) } 451 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 452 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 453 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 454 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 455 FROM CryptographicMessageSyntax-2009 -- [RFC5911] 456 { iso(1) member-body(2) us(840) rsadsi(113549) 457 pkcs(1) pkcs-9(9) smime(16) modules(0) 458 id-mod-cms-2004-02(41) } ; 460 -- 461 -- OtherRecipientInfo Types (ori-) 462 -- 464 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 465 ori-keyTransPSK | 466 ori-keyAgreePSK, 467 ... } 469 -- 470 -- Key Transport with Pre-Shared Key 471 -- 473 ori-keyTransPSK OTHER-RECIPIENT ::= { 474 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 476 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 477 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 479 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 481 KeyTransPSKRecipientInfo ::= SEQUENCE { 482 version CMSVersion, -- always set to 0 483 pskid PreSharedKeyIdentifier, 484 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 485 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 486 ktris KeyTransRecipientInfos, 487 encryptedKey EncryptedKey } 489 PreSharedKeyIdentifier ::= OCTET STRING 491 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 493 -- 494 -- Key Agreement with Pre-Shared Key 495 -- 497 ori-keyAgreePSK ORI-TYPE ::= { 498 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 500 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 502 KeyAgreePSKRecipientInfo ::= SEQUENCE { 503 version CMSVersion, -- always set to 0 504 pskid PreSharedKeyIdentifier, 505 originator [0] EXPLICIT OriginatorIdentifierOrKey, 506 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 507 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 508 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 509 recipientEncryptedKeys RecipientEncryptedKeys } 511 -- 512 -- Structure to provide 'info' input to the KDF 513 -- 515 CMSORIforPSKOtherInfo ::= SEQUENCE { 516 keyMgmtAlgType ENUMERATED { 517 keyTrans (5), 518 keyAgree (10) }, 519 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 520 pskLength INTEGER (1..MAX), 521 kdkLength INTEGER (1..MAX) } 523 END 525 7. Security Considerations 527 Implementations must protect the pre-shared key (PSK), key transport 528 private key, the agreement private key, the key-derivation key, and 529 the key-encryption key. Compromise of the PSK will make the 530 encrypted content vulnerable to the future invention of a large-scale 531 quantum computer. Compromise of the PSK and either the key transport 532 private key or the agreement private key may result in the disclosure 533 of all contents protected with that combination of keying material. 534 Compromise of the PSK and the key-derivation key may result in 535 disclosure of all contents protected with that combination of keying 536 material. Compromise of the key-encryption key may result in the 537 disclosure of all content-encryption keys or content-authenticated- 538 encryption keys that were protected with that keying materail, which 539 in turn may result in the disclosure of the content. 541 A large-scale quantum computer will essentially negate the security 542 provided by the key transport algorithm or the key agreement 543 algorithm, which means that the attacker with a large-scale quantum 544 computer can discover the key-derivation key. In addition a large- 545 scale quantum computer effectively cuts the security provided by a 546 symmetric key algorithm in half. Therefore, the PSK needs at least 547 256 bits of entropy to provide 128 bits of security. To match that 548 same level of security, the key derivation function needs to be 549 quantum-resistant and produce a key-encryption key that is at least 550 256 bits in length. Similarly, the content-encryption key or 551 content-authenticated-encryption key needs to be at least 256 bits in 552 length. 554 Implementations must randomly generate key-derivation keys as well as 555 the content-encryption keys or content-authenticated-encryption keys. 556 Also, the generation of public/private key pairs for the key 557 transport and key agreement algorithms rely on a random numbers. The 558 use of inadequate pseudo-random number generators (PRNGs) to generate 559 cryptographic keys can result in little or no security. An attacker 560 may find it much easier to reproduce the PRNG environment that 561 produced the keys, searching the resulting small set of 562 possibilities, rather than brute force searching the whole key space. 563 The generation of quality random numbers is difficult. [RFC4086] 564 offers important guidance in this area. 566 When using a PSK with a key transport or a key agreement algorithm, a 567 key-encryption key is produced to encrypt the content-encryption key 568 or content-authenticated-encryption key. If the key-encryption 569 algorithm is different than the algorithm used to protect the 570 content, then the effective security is determined by the weaker of 571 the two algorithms. If, for example, content is encrypted with 572 256-bit AES, and the key is wrapped with 128-bit AES, then at most 573 128 bits of protection is provided. Implementers must ensure that 574 the key-encryption algorithm is as strong or stronger than the 575 content-encryption algorithm or content-authenticated-encryption 576 algorithm. 578 Implementers SHOULD NOT mix quantum-resistant key management 579 algorithms with their non-quantum-resistant counterparts. For 580 example, the same content should not be protected with 581 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 582 same content should not be protected with KeyAgreeRecipientInfo and 583 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 584 to the future invention of a large-scale quantum computer. 586 Implementers should not send the same content in different messages, 587 one using a quantum-resistant key management algorithm and the other 588 using a non-quantum-resistant key management algorithm, even if the 589 content-encryption key is generated independently. Doing so may 590 allow an eavesdropper to correlate the messages, making the content 591 vulnerable to the future invention of a large-scale quantum computer. 593 Implementers should be aware that cryptographic algorithms become 594 weaker with time. As new cryptoanalysis techniques are developed and 595 computing performance improves, the work factor to break a particular 596 cryptographic algorithm will be reduced. Therefore, cryptographic 597 algorithm implementations should be modular, allowing new algorithms 598 to be readily inserted. That is, implementors should be prepared for 599 the set of supported algorithms to change over time. 601 8. Privacy Considerations 603 An observer can see which parties are using each PSK simply by 604 watching the PSK key identifiers. However, the addition of these key 605 identifiers is not really making privacy worse. When key transport 606 is used, the RecipientIdentifier is always present, and it clearly 607 identifies each recipient to an observer. When key agreement is 608 used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier 609 is always present, and these clearly identify each recipient. 611 9. IANA Considerations 613 One object identifier for the ASN.1 module in the Section 5 was 614 assigned in the SMI Security for S/MIME Module Identifiers 615 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 617 id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { 618 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 619 pkcs-9(9) smime(16) mod(0) TBD0 } 621 One object identifier for an arc to assign Other Recipient Info 622 Identifiers was assigned in the SMI Security for S/MIME Mail Security 623 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 625 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 626 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 628 This assignment created the new SMI Security for Other Recipient Info 629 Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the 630 following two entries with references to this document: 632 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 633 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 634 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 636 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 637 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 638 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 640 10. References 642 10.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 648 Authenticated-Enveloped-Data Content Type", RFC 5083, 649 November 2007. 651 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 652 5652, September 2009. 654 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 655 2119 Key Words", BCP 14, RFC 8174, May 2017. 657 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 658 One (ASN.1): Specification of basic notation", ITU-T 659 Recommendation X.680, 2015. 661 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 662 Specification of Basic Encoding Rules (BER), Canonical 663 Encoding Rules (CER) and Distinguished Encoding Rules 664 (DER)", ITU-T Recommendation X.690, 2015. 666 10.2. Informative References 668 [AES] National Institute of Standards and Technology, FIPS Pub 669 197: Advanced Encryption Standard (AES), 26 November 2001. 671 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 672 Quantum Cryptography", work-in-progress, draft-hoffman- 673 c2pq-03, February 2018. 675 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 676 numbers.xhtml#security-smime-0. 678 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 679 numbers.xhtml#security-smime. 681 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 682 numbers.xhtml#security-smime-13. 684 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 685 RFC 2631, June 1999. 687 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 688 Algorithm in Cryptographic Message Syntax (CMS)", 689 RFC 3560, July 2003. 691 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 692 "Randomness Requirements for Security", RFC 4086, 693 June 2005. 695 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 696 Cryptography (ECC) Algorithms in Cryptographic Message 697 Syntax (CMS)", RFC 5753, January 2010. 699 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 700 Expand Key Derivation Function (HKDF)", RFC 5869, 701 May 2010. 703 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 704 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 705 June 2010. 707 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 708 Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, 709 June 2010. 711 Acknowledgements 713 Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean 714 Turner, and Daniel Van Geest for their review and insightful 715 comments. They have greatly improved the design, clarity, and 716 implementation guidance. 718 Author's Address 720 Russell Housley 721 Vigil Security, LLC 722 516 Dranesville Road 723 Herndon, VA 20170 724 USA 725 EMail: housley@vigilsec.com