idnits 2.17.1 draft-ietf-lamps-cms-mix-with-psk-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 document date (14 December 2018) is 1958 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 -- Looks like a reference, but probably isn't: '0' on line 523 -- Looks like a reference, but probably isn't: '1' on line 524 == Unused Reference: 'RFC3560' is defined on line 716, 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 (~~), 4 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: 14 June 2019 14 December 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 63 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 64 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 10.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 [RFC8017], 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 [RFC8017], 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 In addition, there may be other reasons for including a strong PSK 114 besides protection against the future invention of a large-scale 115 quantum computer. For example, there is always the possibility of a 116 cryptoanalytic breakthrough on one or more of the classic public-key 117 algorithm, and there are longstanding concerns about undisclosed 118 trapdoors in Diffie-Hellamn parameters. Inclusion of a strong PSK as 119 part of the overall key management offer additional protection 120 against these concerns. 122 Note that the CMS also supports key management techniques based on 123 symmetric key-encryption keys and passwords, but they are not 124 discussed in this document because they are already quantum 125 resistant. The symmetric key-encryption key technique is quantum 126 resistant when used with an adequate key size. The password 127 technique is quantum resistant when used with a quantum-resistant key 128 derivation function and a sufficiently large password. 130 1.1. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 1.2. ASN.1 140 CMS values are generated using ASN.1 [X680], which uses the Basic 141 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 142 [X690]. 144 1.3. Version Numbers 146 The major data structures include a version number as the first item 147 in the data structure. The version number is intended to avoid ASN.1 148 decode errors. Some implementations do not check the version number 149 prior to attempting a decode, and then if a decode error occurs, the 150 version number is checked as part of the error handling routine. 151 This is a reasonable approach; it places error processing outside of 152 the fast path. This approach is also forgiving when an incorrect 153 version number is used by the sender. 155 Whenever the structure is updated, a higher version number will be 156 assigned. However, to ensure maximum interoperability, the higher 157 version number is only used when the new syntax feature is employed. 158 That is, the lowest version number that supports the generated syntax 159 is used. 161 2. Overview 163 The CMS enveloped-data content type [RFC5652] and the CMS 164 authenticated-enveloped-data content type [RFC5083] support both key 165 transport and key agreement public-key algorithms to establish the 166 key used to encrypt the content. No restrictions are imposed on the 167 key transport or key agreement public-key algorithms, which means 168 that any key transport or key agreement algorithm can be used, 169 including algorithms that are specified in the future. In both 170 cases, the sender randomly generates the content-encryption key, and 171 then all recipients obtain that key. All recipients use the sender- 172 generated symmetric content-encryption key for decryption. 174 This specification defines two quantum-resistant ways to establish a 175 symmetric key-encryption key, which is used to encrypt the sender- 176 generated content-encryption key. In both cases, the PSK is used as 177 one of the inputs to a key-derivation function to create a quantum- 178 resistant key-encryption key. The PSK MUST be distributed to the 179 sender and all of the recipients by some out-of-band means that does 180 not make it vulnerable to the future invention of a large-scale 181 quantum computer, and an identifier MUST be assigned to the PSK. 183 The content-encryption key or content-authenticated-encryption key is 184 quantum-resistant, and the sender establishes it using these steps: 186 When using a key transport algorithm: 188 1. The content-encryption key or the content-authenticated- 189 encryption key, called CEK, is generated at random. 191 2. The key-derivation key, called KDK, is generated at random. 193 3. For each recipient, the KDK is encrypted in the recipient's 194 public key, then the key derivation function (KDF) is used to 195 mix the pre-shared key (PSK) and the KDK to produce the key- 196 encryption key, called KEK. 198 4. The KEK is used to encrypt the CEK. 200 When using a key agreement algorithm: 202 1. The content-encryption key or the content-authenticated- 203 encryption key, called CEK, is generated at random. 205 2. For each recipient, a pairwise key-encryption key, called KEK1, 206 is established using the recipient's public key and the 207 sender's private key. 209 3. For each recipient, the key derivation function (KDF) is used 210 to mix the pre-shared key (PSK) and the pairwise KEK1, and the 211 result is called KEK2. 213 4. For each recipient, the pairwise KEK2 is used to encrypt the 214 CEK. 216 As specified in Section 6.2.5 of [RFC5652], recipient information for 217 additional key management techniques are represented in the 218 OtherRecipientInfo type. Two key management techniques are specified 219 in this document, and they are each identified by a unique ASN.1 220 object identifier. 222 The first key management technique, called keyTransPSK, see 223 Section 3, uses a key transport algorithm to transfer the key- 224 derivation key from the sender to the recipient, and then the key- 225 derivation key is mixed with the PSK using a KDF. The output of the 226 KDF is the key-encryption key, which is used for the encryption of 227 the content-encryption key or content-authenticated-encryption key. 229 The second key management technique, called keyAgreePSK, see 230 Section 4, uses a key agreement algorithm to establish a pairwise 231 key-encryption key, which is then mixed with the PSK using a KDF to 232 produce a second pairwise key-encryption key, which is then used to 233 encrypt the content-encryption key or content-authenticated- 234 encryption key. 236 3. KeyTransPSKRecipientInfo 238 Per-recipient information using keyTransPSK is represented in the 239 KeyTransPSKRecipientInfo type, which is indicated by the id-ori- 240 keyTransPSK object identifier. Each instance of 241 KeyTransPSKRecipientInfo establishes the content-encryption key or 242 content-authenticated-encryption key for one or more recipients that 243 have access to the same PSK. 245 The id-ori-keyTransPSK object identifier is: 247 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 248 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 250 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 252 The KeyTransPSKRecipientInfo type is: 254 KeyTransPSKRecipientInfo ::= SEQUENCE { 255 version CMSVersion, -- always set to 0 256 pskid PreSharedKeyIdentifier, 257 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 258 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 259 ktris KeyTransRecipientInfos, 260 encryptedKey EncryptedKey } 262 PreSharedKeyIdentifier ::= OCTET STRING 264 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 266 The fields of the KeyTransPSKRecipientInfo type have the following 267 meanings: 269 version is the syntax version number. The version MUST be 0. The 270 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 272 pskid is the identifier of the PSK used by the sender. The 273 identifier is an OCTET STRING, and it need not be human readable. 275 kdfAlgorithm identifies the key-derivation algorithm, and any 276 associated parameters, used by the sender to mix the key- 277 derivation key and the PSK to generate the key-encryption key. 278 The KeyDerivationAlgorithmIdentifier is described in Section 279 10.1.6 of [RFC5652]. 281 keyEncryptionAlgorithm identifies a key-encryption algorithm used 282 to encrypt the content-encryption key. The 283 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 284 [RFC5652]. 286 ktris contains one KeyTransRecipientInfo type for each recipient; 287 it uses a key transport algorithm to establish the key-derivation 288 key. KeyTransRecipientInfo is described in Section 6.2.1 of 289 [RFC5652]. 291 encryptedKey is the result of encrypting the content-encryption 292 key or the content-authenticated-encryption key with the key- 293 encryption key. EncryptedKey is an OCTET STRING. 295 4. KeyAgreePSKRecipientInfo 297 Per-recipient information using keyAgreePSK is represented in the 298 KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- 299 keyAgreePSK object identifier. Each instance of 300 KeyAgreePSKRecipientInfo establishes the content-encryption key or 301 content-authenticated-encryption key for one or more recipients that 302 have access to the same PSK. 304 The id-ori-keyAgreePSK object identifier is: 306 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 308 The KeyAgreePSKRecipientInfo type is: 310 KeyAgreePSKRecipientInfo ::= SEQUENCE { 311 version CMSVersion, -- always set to 0 312 pskid PreSharedKeyIdentifier, 313 originator [0] EXPLICIT OriginatorIdentifierOrKey, 314 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 315 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 316 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 317 recipientEncryptedKeys RecipientEncryptedKeys } 319 The fields of the KeyAgreePSKRecipientInfo type have the following 320 meanings: 322 version is the syntax version number. The version MUST be 0. The 323 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 325 pskid is the identifier of the PSK used by the sender. The 326 identifier is an OCTET STRING, and it need not be human readable. 328 originator is a CHOICE with three alternatives specifying the 329 sender's key agreement public key. Implementations MUST support 330 all three alternatives for specifying the sender's public key. 331 The sender uses their own private key and the recipient's public 332 key to generate a pairwise key-encryption key. A key derivation 333 function (KDF) is used to mix the PSK and the pairwise key- 334 encryption key to produce a second key-encryption key. The 335 OriginatorIdentifierOrKey type is described in Section 6.2.2 of 336 [RFC5652]. 338 ukm is optional. With some key agreement algorithms, the sender 339 provides a User Keying Material (UKM) to ensure that a different 340 key is generated each time the same two parties generate a 341 pairwise key. Implementations MUST accept a 342 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 343 Implementations that do not support key agreement algorithms that 344 make use of UKMs MUST gracefully handle the presence of UKMs. The 345 UserKeyingMaterial type is described in Section 10.2.6 of 346 [RFC5652]. 348 kdfAlgorithm identifies the key-derivation algorithm, and any 349 associated parameters, used by the sender to mix the pairwise key- 350 encryption key and the PSK to produce a second key-encryption key 351 of the same length as the first one. The 352 KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of 353 [RFC5652]. 355 keyEncryptionAlgorithm identifies a key-encryption algorithm used 356 to encrypt the content-encryption key or the content- 357 authenticated-encryption key. The 358 KeyEncryptionAlgorithmIdentifier type is described in Section 359 10.1.3 of [RFC5652]. 361 recipientEncryptedKeys includes a recipient identifier and 362 encrypted key for one or more recipients. The 363 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 364 specifying the recipient's certificate, and thereby the 365 recipient's public key, that was used by the sender to generate a 366 pairwise key-encryption key. The encryptedKey is the result of 367 encrypting the content-encryption key or the content- 368 authenticated-encryption key with the second pairwise key- 369 encryption key. EncryptedKey is an OCTET STRING. The 370 RecipientEncryptedKeys type is defined in Section 6.2.2 of 371 [RFC5652]. 373 5. Key Derivation 375 Many key derivation functions (KDFs) internally employ a one-way hash 376 function. When this is the case, the hash function that is used is 377 identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] 378 is one example of a KDF that make use fo a hash function. 380 A KDF has several input values. This section describes the 381 conventions for using the KDF to compute the key-encryption key for 382 KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For 383 simplicity, the terminology used in the HKDF [RFC5869] specification 384 is used here. 386 The KDF inputs are: 388 IKM is the input keying material; it is the symmetric secret input 389 to the KDF. For KeyTransPSKRecipientInfo, it is the PSK 390 concatenated with the key-derivation key. For 391 KeyAgreePSKRecipientInfo, it is the PSK concatenated with the 392 pairwise key-encryption key produced by the key agreement 393 algorithm. 395 salt is an optional non-secret random value. The salt is not 396 used. 398 L is the length of output keying material in octets; the value 399 depends on the key-encryption algorithm that will be used. The 400 algorithm is identified by the KeyEncryptionAlgorithmIdentifier. 401 In addition, the OBJECT IDENTIFIER portion of the 402 KeyEncryptionAlgorithmIdentifier is included in the next input 403 value, called info. 405 info is optional context and application specific information. 406 The DER-encoding of CMSORIforPSKOtherInfo is used as the info 407 value. Note that EXPLICIT tagging is used in the ASN.1 module 408 that deines this structure. For KeyTransPSKRecipientInfo, the 409 ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the 410 ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined 411 by the following ASN.1 structure: 413 CMSORIforPSKOtherInfo ::= SEQUENCE { 414 keyMgmtAlgType ENUMERATED { 415 keyTrans (5), 416 keyAgree (10) }, 417 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 418 pskLength INTEGER (1..MAX), 419 kdkLength INTEGER (1..MAX) } 421 The fields of type CMSORIforPSKOtherInfo have the following meanings: 423 keyMgmtAlgType is either set to 5 or 10. For 424 KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For 425 KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. 427 keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, 428 which identifies the algorithm and provides algorithm parameters, 429 if any. 431 pskLength is a positive integer; it contains the length of the PSK 432 in octets. 434 kdkLength is a positive integer; it contains the length of the 435 key-derivation key in octets. For KeyTransPSKRecipientInfo, the 436 key-derivation key is generated by the sender. For 437 KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise 438 key-encryption key produced by the key agreement algorithm. 440 The KDF output is: 442 OKM is the output keying material, which is exactly L octets. The 443 OKM is the key-encryption key that is used to encrypt the content- 444 encryption key or the content-authenticated-encryption key. 446 6. ASN.1 Module 448 This section contains the ASN.1 module for the two key management 449 techniques defined in this document. This module imports types from 450 other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. 452 CMSORIforPSK-2017 453 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 454 smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) } 456 DEFINITIONS EXPLICIT TAGS ::= 457 BEGIN 459 -- EXPORTS All 461 IMPORTS 463 AlgorithmIdentifier{}, KEY-DERIVATION 464 FROM AlgorithmInformation-2009 -- [RFC5912] 465 { iso(1) identified-organization(3) dod(6) internet(1) 466 security(5) mechanisms(5) pkix(7) id-mod(0) 467 id-mod-algorithmInformation-02(58) } 469 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 470 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 471 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 472 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 473 FROM CryptographicMessageSyntax-2009 -- [RFC5911] 474 { iso(1) member-body(2) us(840) rsadsi(113549) 475 pkcs(1) pkcs-9(9) smime(16) modules(0) 476 id-mod-cms-2004-02(41) } ; 478 -- 479 -- OtherRecipientInfo Types (ori-) 480 -- 482 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 483 ori-keyTransPSK | 484 ori-keyAgreePSK, 485 ... } 487 -- 488 -- Key Transport with Pre-Shared Key 489 -- 491 ori-keyTransPSK OTHER-RECIPIENT ::= { 492 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 494 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 495 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 497 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 499 KeyTransPSKRecipientInfo ::= SEQUENCE { 500 version CMSVersion, -- always set to 0 501 pskid PreSharedKeyIdentifier, 502 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 503 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 504 ktris KeyTransRecipientInfos, 505 encryptedKey EncryptedKey } 507 PreSharedKeyIdentifier ::= OCTET STRING 509 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 511 -- 512 -- Key Agreement with Pre-Shared Key 513 -- 515 ori-keyAgreePSK ORI-TYPE ::= { 516 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 518 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 520 KeyAgreePSKRecipientInfo ::= SEQUENCE { 521 version CMSVersion, -- always set to 0 522 pskid PreSharedKeyIdentifier, 523 originator [0] EXPLICIT OriginatorIdentifierOrKey, 524 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 525 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 526 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 527 recipientEncryptedKeys RecipientEncryptedKeys } 529 -- 530 -- Structure to provide 'info' input to the KDF 531 -- 533 CMSORIforPSKOtherInfo ::= SEQUENCE { 534 keyMgmtAlgType ENUMERATED { 535 keyTrans (5), 536 keyAgree (10) }, 537 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 538 pskLength INTEGER (1..MAX), 539 kdkLength INTEGER (1..MAX) } 541 END 543 7. Security Considerations 545 Implementations must protect the pre-shared key (PSK), key transport 546 private key, the agreement private key, the key-derivation key, and 547 the key-encryption key. Compromise of the PSK will make the 548 encrypted content vulnerable to the future invention of a large-scale 549 quantum computer. Compromise of the PSK and either the key transport 550 private key or the agreement private key may result in the disclosure 551 of all contents protected with that combination of keying material. 552 Compromise of the PSK and the key-derivation key may result in 553 disclosure of all contents protected with that combination of keying 554 material. Compromise of the key-encryption key may result in the 555 disclosure of all content-encryption keys or content-authenticated- 556 encryption keys that were protected with that keying materail, which 557 in turn may result in the disclosure of the content. 559 A large-scale quantum computer will essentially negate the security 560 provided by the key transport algorithm or the key agreement 561 algorithm, which means that the attacker with a large-scale quantum 562 computer can discover the key-derivation key. In addition a large- 563 scale quantum computer effectively cuts the security provided by a 564 symmetric key algorithm in half. Therefore, the PSK needs at least 565 256 bits of entropy to provide 128 bits of security. To match that 566 same level of security, the key derivation function needs to be 567 quantum-resistant and produce a key-encryption key that is at least 568 256 bits in length. Similarly, the content-encryption key or 569 content-authenticated-encryption key needs to be at least 256 bits in 570 length. 572 When using a PSK with a key transport or a key agreement algorithm, a 573 key-encryption key is produced to encrypt the content-encryption key 574 or content-authenticated-encryption key. If the key-encryption 575 algorithm is different than the algorithm used to protect the 576 content, then the effective security is determined by the weaker of 577 the two algorithms. If, for example, content is encrypted with 578 256-bit AES, and the key is wrapped with 128-bit AES, then at most 579 128 bits of protection is provided. Implementers must ensure that 580 the key-encryption algorithm is as strong or stronger than the 581 content-encryption algorithm or content-authenticated-encryption 582 algorithm. 584 Implementers should not mix quantum-resistant key management 585 algorithms with their non-quantum-resistant counterparts. For 586 example, the same content should not be protected with 587 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 588 same content should not be protected with KeyAgreeRecipientInfo and 589 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 590 to the future invention of a large-scale quantum computer. 592 Implementers should not send the same content in different messages, 593 one using a quantum-resistant key management algorithm and the other 594 using a non-quantum-resistant key management algorithm, even if the 595 content-encryption key is generated independently. Doing so may 596 allow an eavesdropper to correlate the messages, making the content 597 vulnerable to the future invention of a large-scale quantum computer. 599 Sound cryptographic key hygiene is to use a key for one and only one 600 purpose. Use of the recipient's public key for both the traditional 601 CMS and the PSK-mixing variation specified in this document would be 602 a violations of this principle; however, there is no known way for an 603 attacker to take advantage of this situation. However, an 604 application should enforce separation whenever possible. For 605 example, an purpose identifier for use in the X.509 extended key 606 usage certificate extension [RFC5280] could be identified in the 607 future to indicate that a public key should only be used in 608 conjunction with a PSK, or only without. 610 Implementations must randomly generate key-derivation keys as well as 611 the content-encryption keys or content-authenticated-encryption keys. 612 Also, the generation of public/private key pairs for the key 613 transport and key agreement algorithms rely on a random numbers. The 614 use of inadequate pseudo-random number generators (PRNGs) to generate 615 cryptographic keys can result in little or no security. An attacker 616 may find it much easier to reproduce the PRNG environment that 617 produced the keys, searching the resulting small set of 618 possibilities, rather than brute force searching the whole key space. 619 The generation of quality random numbers is difficult. [RFC4086] 620 offers important guidance in this area. 622 Implementers should be aware that cryptographic algorithms become 623 weaker with time. As new cryptoanalysis techniques are developed and 624 computing performance improves, the work factor to break a particular 625 cryptographic algorithm will be reduced. Therefore, cryptographic 626 algorithm implementations should be modular, allowing new algorithms 627 to be readily inserted. That is, implementors should be prepared for 628 the set of supported algorithms to change over time. 630 8. Privacy Considerations 632 An observer can see which parties are using each PSK simply by 633 watching the PSK key identifiers. However, the addition of these key 634 identifiers is not really making privacy worse. When key transport 635 is used, the RecipientIdentifier is always present, and it clearly 636 identifies each recipient to an observer. When key agreement is 637 used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier 638 is always present, and these clearly identify each recipient. 640 9. IANA Considerations 642 One object identifier for the ASN.1 module in the Section 5 was 643 assigned in the SMI Security for S/MIME Module Identifiers 644 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 646 id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { 647 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 648 pkcs-9(9) smime(16) mod(0) TBD0 } 650 One object identifier for an arc to assign Other Recipient Info 651 Identifiers was assigned in the SMI Security for S/MIME Mail Security 652 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 654 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 655 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 657 This assignment created the new SMI Security for Other Recipient Info 658 Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the 659 following two entries with references to this document: 661 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 662 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 663 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 665 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 666 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 667 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 669 10. References 671 10.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 677 Authenticated-Enveloped-Data Content Type", RFC 5083, 678 November 2007. 680 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 681 5652, September 2009. 683 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 684 2119 Key Words", BCP 14, RFC 8174, May 2017. 686 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 687 One (ASN.1): Specification of basic notation", ITU-T 688 Recommendation X.680, 2015. 690 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 691 Specification of Basic Encoding Rules (BER), Canonical 692 Encoding Rules (CER) and Distinguished Encoding Rules 693 (DER)", ITU-T Recommendation X.690, 2015. 695 10.2. Informative References 697 [AES] National Institute of Standards and Technology, FIPS Pub 698 197: Advanced Encryption Standard (AES), 26 November 2001. 700 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 701 Quantum Cryptography", work-in-progress, draft-hoffman- 702 c2pq-03, February 2018. 704 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 705 numbers.xhtml#security-smime-0. 707 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 708 numbers.xhtml#security-smime. 710 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 711 numbers.xhtml#security-smime-13. 713 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 714 RFC 2631, June 1999. 716 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 717 Algorithm in Cryptographic Message Syntax (CMS)", 718 RFC 3560, July 2003. 720 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 721 "Randomness Requirements for Security", RFC 4086, 722 June 2005. 724 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 725 Housley, R., and W. Polk, "Internet X.509 Public Key 726 Infrastructure Certificate and Certificate Revocation List 727 (CRL) Profile", RFC 5280, May 2008. 729 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 730 Cryptography (ECC) Algorithms in Cryptographic Message 731 Syntax (CMS)", RFC 5753, January 2010. 733 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 734 Expand Key Derivation Function (HKDF)", RFC 5869, 735 May 2010. 737 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 738 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 739 June 2010. 741 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 742 Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, 743 June 2010. 745 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 746 "PKCS #1: RSA Cryptography Specifications Version 2.2", 747 RFC 8017, November 2016. 749 Acknowledgements 751 Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean 752 Turner, and Daniel Van Geest for their review and insightful 753 comments. They have greatly improved the design, clarity, and 754 implementation guidance. 756 Author's Address 758 Russell Housley 759 Vigil Security, LLC 760 516 Dranesville Road 761 Herndon, VA 20170 762 USA 763 EMail: housley@vigilsec.com