idnits 2.17.1 draft-ietf-lamps-cms-mix-with-psk-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 August 2019) is 1723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1237 -- Looks like a reference, but probably isn't: '1' on line 1187 -- Looks like a reference, but probably isn't: '4' on line 1180 -- Looks like a reference, but probably isn't: '2' on line 1116 == Unused Reference: 'RFC6268' is defined on line 796, 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-04 Summary: 0 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 Internet Engineering Task Force (IETF) Vigil Security 4 Intended Status: Proposed Standard 5 Expires: 6 February 2020 6 August 2019 7 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) 8 10 Abstract 12 The invention of a large-scale quantum computer would pose a serious 13 challenge for the cryptographic algorithms that are widely deployed 14 today. The Cryptographic Message Syntax (CMS) supports key transport 15 and key agreement algorithms that could be broken by the invention of 16 such a quantum computer. By storing communications that are 17 protected with the CMS today, someone could decrypt them in the 18 future when a large-scale quantum computer becomes available. Once 19 quantum-secure key management algorithms are available, the CMS will 20 be extended to support the new algorithms, if the existing syntax 21 does not accommodate them. In the near-term, this document describes 22 a mechanism to protect today's communication from the future 23 invention of a large-scale quantum computer by mixing the output of 24 key transport and key agreement algorithms with a pre-shared key. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 64 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 65 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 72 10.2. Informative References . . . . . . . . . . . . . . . . . 16 73 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17 74 A.1. Originator Processing Example . . . . . . . . . . . . . . 18 75 A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20 76 A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22 77 Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23 78 B.1. Originator Processing Example . . . . . . . . . . . . . . 23 79 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 80 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 1. Introduction 86 The invention of a large-scale quantum computer would pose a serious 87 challenge for the cryptographic algorithms that are widely deployed 88 today [S1994]. It is an open question whether or not it is feasible 89 to build a large-scale quantum computer, and if so, when that might 90 happen [NAS2019]. However, if such a quantum computer is invented, 91 many of the cryptographic algorithms and the security protocols that 92 use them would become vulnerable. 94 The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports 95 key transport and key agreement algorithms that could be broken by 96 the invention of a large-scale quantum computer [C2PQ]. These 97 algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and 98 Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary 99 that stores CMS-protected communications today, could decrypt those 100 communications in the future when a large-scale quantum computer 101 becomes available. 103 Once quantum-secure key management algorithms are available, the CMS 104 will be extended to support them, if the existing syntax does not 105 already accommodate the new algorithms. 107 In the near-term, this document describes a mechanism to protect 108 today's communication from the future invention of a large-scale 109 quantum computer by mixing the output of existing key transport and 110 key agreement algorithms with a pre-shared key (PSK). Secure 111 communication can be achieved today by mixing a strong PSK with the 112 output of an existing key transport algorithm, like RSA [RFC8017], or 113 an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or 114 Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is 115 believed to be quantum resistant can be achieved by using a PSK with 116 sufficient entropy along with a quantum resistant key derivation 117 function (KDF), like HKDF [RFC5869], and a quantum resistant 118 encryption algorithm, like 256-bit AES [AES]. In this way, today's 119 CMS-protected communication can be resistant to an attacker with a 120 large-scale quantum computer. 122 In addition, there may be other reasons for including a strong PSK 123 besides protection against the future invention of a large-scale 124 quantum computer. For example, there is always the possibility of a 125 cryptoanalytic breakthrough on one or more of the classic public-key 126 algorithm, and there are longstanding concerns about undisclosed 127 trapdoors in Diffie-Hellman parameters [FGHT2016]. Inclusion of a 128 strong PSK as part of the overall key management offer additional 129 protection against these concerns. 131 Note that the CMS also supports key management techniques based on 132 symmetric key-encryption keys and passwords, but they are not 133 discussed in this document because they are already quantum 134 resistant. The symmetric key-encryption key technique is quantum 135 resistant when used with an adequate key size. The password 136 technique is quantum resistant when used with a quantum-resistant key 137 derivation function and a sufficiently large password. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 1.2. ASN.1 149 CMS values are generated using ASN.1 [X680], which uses the Basic 150 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 151 [X690]. 153 1.3. Version Numbers 155 The major data structures include a version number as the first item 156 in the data structure. The version number is intended to avoid ASN.1 157 decode errors. Some implementations do not check the version number 158 prior to attempting a decode, and then if a decode error occurs, the 159 version number is checked as part of the error handling routine. 160 This is a reasonable approach; it places error processing outside of 161 the fast path. This approach is also forgiving when an incorrect 162 version number is used by the sender. 164 Whenever the structure is updated, a higher version number will be 165 assigned. However, to ensure maximum interoperability, the higher 166 version number is only used when the new syntax feature is employed. 167 That is, the lowest version number that supports the generated syntax 168 is used. 170 2. Overview 172 The CMS enveloped-data content type [RFC5652] and the CMS 173 authenticated-enveloped-data content type [RFC5083] support both key 174 transport and key agreement public-key algorithms to establish the 175 key used to encrypt the content. No restrictions are imposed on the 176 key transport or key agreement public-key algorithms, which means 177 that any key transport or key agreement algorithm can be used, 178 including algorithms that are specified in the future. In both 179 cases, the sender randomly generates the content-encryption key, and 180 then all recipients obtain that key. All recipients use the sender- 181 generated symmetric content-encryption key for decryption. 183 This specification defines two quantum-resistant ways to establish a 184 symmetric key-encryption key, which is used to encrypt the sender- 185 generated content-encryption key. In both cases, the PSK is used as 186 one of the inputs to a key-derivation function to create a quantum- 187 resistant key-encryption key. The PSK MUST be distributed to the 188 sender and all of the recipients by some out-of-band means that does 189 not make it vulnerable to the future invention of a large-scale 190 quantum computer, and an identifier MUST be assigned to the PSK. 192 The content-encryption key or content-authenticated-encryption key is 193 quantum-resistant, and the sender establishes it using these steps: 195 When using a key transport algorithm: 197 1. The content-encryption key or the content-authenticated- 198 encryption key, called CEK, is generated at random. 200 2. The key-derivation key, called KDK, is generated at random. 202 3. For each recipient, the KDK is encrypted in the recipient's 203 public key, then the key derivation function (KDF) is used to 204 mix the pre-shared key (PSK) and the KDK to produce the key- 205 encryption key, called KEK. 207 4. The KEK is used to encrypt the CEK. 209 When using a key agreement algorithm: 211 1. The content-encryption key or the content-authenticated- 212 encryption key, called CEK, is generated at random. 214 2. For each recipient, a pairwise key-encryption key, called KEK1, 215 is established using the recipient's public key and the 216 sender's private key. Note that KEK1 will be used as a key- 217 derivation key. 219 3. For each recipient, the key derivation function (KDF) is used 220 to mix the pre-shared key (PSK) and the pairwise KEK1, and the 221 result is called KEK2. 223 4. For each recipient, the pairwise KEK2 is used to encrypt the 224 CEK. 226 As specified in Section 6.2.5 of [RFC5652], recipient information for 227 additional key management techniques are represented in the 228 OtherRecipientInfo type. Two key management techniques are specified 229 in this document, and they are each identified by a unique ASN.1 230 object identifier. 232 The first key management technique, called keyTransPSK, see 233 Section 3, uses a key transport algorithm to transfer the key- 234 derivation key from the sender to the recipient, and then the key- 235 derivation key is mixed with the PSK using a KDF. The output of the 236 KDF is the key-encryption key, which is used for the encryption of 237 the content-encryption key or content-authenticated-encryption key. 239 The second key management technique, called keyAgreePSK, see 240 Section 4, uses a key agreement algorithm to establish a pairwise 241 key-encryption key, which is then mixed with the PSK using a KDF to 242 produce a second pairwise key-encryption key, which is then used to 243 encrypt the content-encryption key or content-authenticated- 244 encryption key. 246 3. keyTransPSK 248 Per-recipient information using keyTransPSK is represented in the 249 KeyTransPSKRecipientInfo type, which is indicated by the id-ori- 250 keyTransPSK object identifier. Each instance of 251 KeyTransPSKRecipientInfo establishes the content-encryption key or 252 content-authenticated-encryption key for one or more recipients that 253 have access to the same PSK. 255 The id-ori-keyTransPSK object identifier is: 257 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 258 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 260 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 262 The KeyTransPSKRecipientInfo type is: 264 KeyTransPSKRecipientInfo ::= SEQUENCE { 265 version CMSVersion, -- always set to 0 266 pskid PreSharedKeyIdentifier, 267 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 268 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 269 ktris KeyTransRecipientInfos, 270 encryptedKey EncryptedKey } 272 PreSharedKeyIdentifier ::= OCTET STRING 274 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 276 The fields of the KeyTransPSKRecipientInfo type have the following 277 meanings: 279 version is the syntax version number. The version MUST be 0. The 280 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 282 pskid is the identifier of the PSK used by the sender. The 283 identifier is an OCTET STRING, and it need not be human readable. 285 kdfAlgorithm identifies the key-derivation algorithm, and any 286 associated parameters, used by the sender to mix the key- 287 derivation key and the PSK to generate the key-encryption key. 288 The KeyDerivationAlgorithmIdentifier is described in Section 289 10.1.6 of [RFC5652]. 291 keyEncryptionAlgorithm identifies a key-encryption algorithm used 292 to encrypt the content-encryption key. The 293 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 294 [RFC5652]. 296 ktris contains one KeyTransRecipientInfo type for each recipient; 297 it uses a key transport algorithm to establish the key-derivation 298 key. KeyTransRecipientInfo is described in Section 6.2.1 of 299 [RFC5652]. 301 encryptedKey is the result of encrypting the content-encryption 302 key or the content-authenticated-encryption key with the key- 303 encryption key. EncryptedKey is an OCTET STRING. 305 4. keyAgreePSK 307 Per-recipient information using keyAgreePSK is represented in the 308 KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- 309 keyAgreePSK object identifier. Each instance of 310 KeyAgreePSKRecipientInfo establishes the content-encryption key or 311 content-authenticated-encryption key for one or more recipients that 312 have access to the same PSK. 314 The id-ori-keyAgreePSK object identifier is: 316 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 318 The KeyAgreePSKRecipientInfo type is: 320 KeyAgreePSKRecipientInfo ::= SEQUENCE { 321 version CMSVersion, -- always set to 0 322 pskid PreSharedKeyIdentifier, 323 originator [0] EXPLICIT OriginatorIdentifierOrKey, 324 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 325 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 326 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 327 recipientEncryptedKeys RecipientEncryptedKeys } 329 The fields of the KeyAgreePSKRecipientInfo type have the following 330 meanings: 332 version is the syntax version number. The version MUST be 0. The 333 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 335 pskid is the identifier of the PSK used by the sender. The 336 identifier is an OCTET STRING, and it need not be human readable. 338 originator is a CHOICE with three alternatives specifying the 339 sender's key agreement public key. Implementations MUST support 340 all three alternatives for specifying the sender's public key. 341 The sender uses their own private key and the recipient's public 342 key to generate a pairwise key-encryption key. A key derivation 343 function (KDF) is used to mix the PSK and the pairwise key- 344 encryption key to produce a second key-encryption key. The 345 OriginatorIdentifierOrKey type is described in Section 6.2.2 of 346 [RFC5652]. 348 ukm is optional. With some key agreement algorithms, the sender 349 provides a User Keying Material (UKM) to ensure that a different 350 key is generated each time the same two parties generate a 351 pairwise key. Implementations MUST accept a 352 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 353 Implementations that do not support key agreement algorithms that 354 make use of UKMs MUST gracefully handle the presence of UKMs. The 355 UserKeyingMaterial type is described in Section 10.2.6 of 356 [RFC5652]. 358 kdfAlgorithm identifies the key-derivation algorithm, and any 359 associated parameters, used by the sender to mix the pairwise key- 360 encryption key and the PSK to produce a second key-encryption key 361 of the same length as the first one. The 362 KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of 363 [RFC5652]. 365 keyEncryptionAlgorithm identifies a key-encryption algorithm used 366 to encrypt the content-encryption key or the content- 367 authenticated-encryption key. The 368 KeyEncryptionAlgorithmIdentifier type is described in Section 369 10.1.3 of [RFC5652]. 371 recipientEncryptedKeys includes a recipient identifier and 372 encrypted key for one or more recipients. The 373 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 374 specifying the recipient's certificate, and thereby the 375 recipient's public key, that was used by the sender to generate a 376 pairwise key-encryption key. The encryptedKey is the result of 377 encrypting the content-encryption key or the content- 378 authenticated-encryption key with the second pairwise key- 379 encryption key. EncryptedKey is an OCTET STRING. The 380 RecipientEncryptedKeys type is defined in Section 6.2.2 of 381 [RFC5652]. 383 5. Key Derivation 385 Many key derivation functions (KDFs) internally employ a one-way hash 386 function. When this is the case, the hash function that is used is 387 identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] 388 is one example of a KDF that makes use of a hash function. 390 A KDF has several input values. This section describes the 391 conventions for using the KDF to compute the key-encryption key for 392 KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For 393 simplicity, the terminology used in the HKDF [RFC5869] specification 394 is used here. 396 The KDF inputs are: 398 IKM is the input keying material; it is the symmetric secret input 399 to the KDF. For KeyTransPSKRecipientInfo, it is the key- 400 derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise 401 key-encryption key produced by the key agreement algorithm. 403 salt is an optional non-secret random value. The salt is not 404 used. 406 L is the length of output keying material in octets; the value 407 depends on the key-encryption algorithm that will be used. The 408 algorithm is identified by the KeyEncryptionAlgorithmIdentifier. 409 In addition, the OBJECT IDENTIFIER portion of the 410 KeyEncryptionAlgorithmIdentifier is included in the next input 411 value, called info. 413 info is optional context and application specific information. 414 The DER-encoding of CMSORIforPSKOtherInfo is used as the info 415 value, and the PSK is included in this structure. Note that 416 EXPLICIT tagging is used in the ASN.1 module that defines this 417 structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of 418 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 419 10 is used. CMSORIforPSKOtherInfo is defined by the following 420 ASN.1 structure: 422 CMSORIforPSKOtherInfo ::= SEQUENCE { 423 psk OCTET STRING, 424 keyMgmtAlgType ENUMERATED { 425 keyTrans (5), 426 keyAgree (10) }, 427 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 428 pskLength INTEGER (1..MAX), 429 kdkLength INTEGER (1..MAX) } 431 The fields of type CMSORIforPSKOtherInfo have the following meanings: 433 psk is an OCTET STRING; it contains the PSK. 435 keyMgmtAlgType is either set to 5 or 10. For 436 KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For 437 KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. 439 keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, 440 which identifies the algorithm and provides algorithm parameters, 441 if any. 443 pskLength is a positive integer; it contains the length of the PSK 444 in octets. 446 kdkLength is a positive integer; it contains the length of the 447 key-derivation key in octets. For KeyTransPSKRecipientInfo, the 448 key-derivation key is generated by the sender. For 449 KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise 450 key-encryption key produced by the key agreement algorithm. 452 The KDF output is: 454 OKM is the output keying material, which is exactly L octets. The 455 OKM is the key-encryption key that is used to encrypt the content- 456 encryption key or the content-authenticated-encryption key. 458 6. ASN.1 Module 460 This section contains the ASN.1 module for the two key management 461 techniques defined in this document. This module imports types from 462 other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. 464 466 CMSORIforPSK-2019 467 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 468 smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) } 470 DEFINITIONS EXPLICIT TAGS ::= 471 BEGIN 473 -- EXPORTS All 475 IMPORTS 477 AlgorithmIdentifier{}, KEY-DERIVATION 478 FROM AlgorithmInformation-2009 -- [RFC5912] 479 { iso(1) identified-organization(3) dod(6) internet(1) 480 security(5) mechanisms(5) pkix(7) id-mod(0) 481 id-mod-algorithmInformation-02(58) } 483 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 484 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 485 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 486 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 487 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 488 { iso(1) member-body(2) us(840) rsadsi(113549) 489 pkcs(1) pkcs-9(9) smime(16) modules(0) 490 id-mod-cms-2009(58) } ; 492 -- 493 -- OtherRecipientInfo Types (ori-) 494 -- 496 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 497 ori-keyTransPSK | 498 ori-keyAgreePSK, 499 ... } 501 -- 502 -- Key Transport with Pre-Shared Key 503 -- 505 ori-keyTransPSK OTHER-RECIPIENT ::= { 506 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 508 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 509 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 511 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 512 KeyTransPSKRecipientInfo ::= SEQUENCE { 513 version CMSVersion, -- always set to 0 514 pskid PreSharedKeyIdentifier, 515 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 516 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 517 ktris KeyTransRecipientInfos, 518 encryptedKey EncryptedKey } 520 PreSharedKeyIdentifier ::= OCTET STRING 522 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 524 -- 525 -- Key Agreement with Pre-Shared Key 526 -- 528 ori-keyAgreePSK OTHER-RECIPIENT ::= { 529 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 531 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 533 KeyAgreePSKRecipientInfo ::= SEQUENCE { 534 version CMSVersion, -- always set to 0 535 pskid PreSharedKeyIdentifier, 536 originator [0] EXPLICIT OriginatorIdentifierOrKey, 537 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 538 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 539 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 540 recipientEncryptedKeys RecipientEncryptedKeys } 542 -- 543 -- Structure to provide 'info' input to the KDF, 544 -- including the Pre-Shared Key 545 -- 547 CMSORIforPSKOtherInfo ::= SEQUENCE { 548 psk OCTET STRING, 549 keyMgmtAlgType ENUMERATED { 550 keyTrans (5), 551 keyAgree (10) }, 552 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 553 pskLength INTEGER (1..MAX), 554 kdkLength INTEGER (1..MAX) } 556 END 558 560 7. Security Considerations 562 Implementations must protect the pre-shared key (PSK), key transport 563 private key, the agreement private key, the key-derivation key, and 564 the key-encryption key. Compromise of the PSK will make the 565 encrypted content vulnerable to the future invention of a large-scale 566 quantum computer. Compromise of the PSK and either the key transport 567 private key or the agreement private key may result in the disclosure 568 of all contents protected with that combination of keying material. 569 Compromise of the PSK and the key-derivation key may result in 570 disclosure of all contents protected with that combination of keying 571 material. Compromise of the key-encryption key may result in the 572 disclosure of all content-encryption keys or content-authenticated- 573 encryption keys that were protected with that keying material, which 574 in turn may result in the disclosure of the content. 576 A large-scale quantum computer will essentially negate the security 577 provided by the key transport algorithm or the key agreement 578 algorithm, which means that the attacker with a large-scale quantum 579 computer can discover the key-derivation key. In addition a large- 580 scale quantum computer effectively cuts the security provided by a 581 symmetric key algorithm in half. Therefore, the PSK needs at least 582 256 bits of entropy to provide 128 bits of security. To match that 583 same level of security, the key derivation function needs to be 584 quantum-resistant and produce a key-encryption key that is at least 585 256 bits in length. Similarly, the content-encryption key or 586 content-authenticated-encryption key needs to be at least 256 bits in 587 length. 589 When using a PSK with a key transport or a key agreement algorithm, a 590 key-encryption key is produced to encrypt the content-encryption key 591 or content-authenticated-encryption key. If the key-encryption 592 algorithm is different than the algorithm used to protect the 593 content, then the effective security is determined by the weaker of 594 the two algorithms. If, for example, content is encrypted with 595 256-bit AES, and the key is wrapped with 128-bit AES, then at most 596 128 bits of protection is provided. Implementers must ensure that 597 the key-encryption algorithm is as strong or stronger than the 598 content-encryption algorithm or content-authenticated-encryption 599 algorithm. 601 Implementers should not mix quantum-resistant key management 602 algorithms with their non-quantum-resistant counterparts. For 603 example, the same content should not be protected with 604 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 605 same content should not be protected with KeyAgreeRecipientInfo and 606 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 607 to the future invention of a large-scale quantum computer. 609 Implementers should not send the same content in different messages, 610 one using a quantum-resistant key management algorithm and the other 611 using a non-quantum-resistant key management algorithm, even if the 612 content-encryption key is generated independently. Doing so may 613 allow an eavesdropper to correlate the messages, making the content 614 vulnerable to the future invention of a large-scale quantum computer. 616 This specification does not require that PSK is known only by the 617 sender and recipients. The PSK may be known to a group. Since 618 confidentiality depends on the key transport or key agreement 619 algorithm, knowledge of the PSK by other parties does not enable 620 eavesdropping. However, group members can record the traffic of 621 other members, and then decrypt it if they ever gain access to a 622 large-scale quantum computer. Also, when many parties know the PSK, 623 there are many opportunities for theft of the PSK by an attacker. 624 Once an attacker has the PSK, they can decrypt stored traffic if they 625 ever gain access to a large-scale quantum computer in the same manner 626 as a legitimate group member. 628 Sound cryptographic key hygiene is to use a key for one and only one 629 purpose. Use of the recipient's public key for both the traditional 630 CMS and the PSK-mixing variation specified in this document would be 631 a violation of this principle; however, there is no known way for an 632 attacker to take advantage of this situation. That said, an 633 application should enforce separation whenever possible. For 634 example, a purpose identifier for use in the X.509 extended key usage 635 certificate extension [RFC5280] could be identified in the future to 636 indicate that a public key should only be used in conjunction with a 637 PSK, or only without. 639 Implementations must randomly generate key-derivation keys as well as 640 the content-encryption keys or content-authenticated-encryption keys. 641 Also, the generation of public/private key pairs for the key 642 transport and key agreement algorithms rely on a random numbers. The 643 use of inadequate pseudo-random number generators (PRNGs) to generate 644 cryptographic keys can result in little or no security. An attacker 645 may find it much easier to reproduce the PRNG environment that 646 produced the keys, searching the resulting small set of 647 possibilities, rather than brute force searching the whole key space. 648 The generation of quality random numbers is difficult. [RFC4086] 649 offers important guidance in this area. 651 Implementers should be aware that cryptographic algorithms become 652 weaker with time. As new cryptoanalysis techniques are developed and 653 computing performance improves, the work factor to break a particular 654 cryptographic algorithm will be reduced. Therefore, cryptographic 655 algorithm implementations should be modular, allowing new algorithms 656 to be readily inserted. That is, implementers should be prepared for 657 the set of supported algorithms to change over time. 659 The security properties provided by the mechanisms specified in this 660 document can be validated using formal methods. A ProVerif proof in 661 [H2019] shows that an attacker with a large-scale quantum computer 662 that is capable of breaking the Diffie-Hellman key agreement 663 algorithm cannot disrupt the delivery of the content-encryption key 664 to the recipient and the attacker cannot learn the content-encryption 665 key from the protocol exchange. 667 8. Privacy Considerations 669 An observer can see which parties are using each PSK simply by 670 watching the PSK key identifiers. However, the addition of these key 671 identifiers is not really making privacy worse. When key transport 672 is used, the RecipientIdentifier is always present, and it clearly 673 identifies each recipient to an observer. When key agreement is 674 used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier 675 is always present, and these clearly identify each recipient. 677 9. IANA Considerations 679 One object identifier for the ASN.1 module in Section 6 was assigned 680 in the SMI Security for S/MIME Module Identifiers 681 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 683 id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { 684 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 685 pkcs-9(9) smime(16) mod(0) TBD0 } 687 One new registry was created for Other Recipient Info Identifiers 688 within the SMI Security for S/MIME Mail Security 689 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 691 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 692 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 694 Two assignments were made in the new SMI Security for Other Recipient 695 Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry 696 with references to this document: 698 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 699 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 700 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 702 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 703 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 704 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 706 10. References 708 10.1. Normative References 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, March 1997. 713 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 714 Authenticated-Enveloped-Data Content Type", RFC 5083, 715 November 2007. 717 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 718 5652, September 2009. 720 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 721 2119 Key Words", BCP 14, RFC 8174, May 2017. 723 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 724 One (ASN.1): Specification of basic notation", ITU-T 725 Recommendation X.680, 2015. 727 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 728 Specification of Basic Encoding Rules (BER), Canonical 729 Encoding Rules (CER) and Distinguished Encoding Rules 730 (DER)", ITU-T Recommendation X.690, 2015. 732 10.2. Informative References 734 [AES] National Institute of Standards and Technology, FIPS Pub 735 197: Advanced Encryption Standard (AES), 26 November 2001. 737 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 738 Quantum Cryptography", work-in-progress, draft-hoffman- 739 c2pq-04, August 2018. 741 [FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A 742 kilobit hidden SNFS discrete logarithm computation", 743 Cryptology ePrint Archive, Report 2016/961, 2016. 744 https://eprint.iacr.org/2016/961.pdf. 746 [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- 747 lamps-cms-mix-with-psk", , 27 May 2019. 750 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 751 numbers.xhtml#security-smime-0. 753 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 754 numbers.xhtml#security-smime. 756 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 757 numbers.xhtml#security-smime-TBD1. 759 [NAS2019] National Academies of Sciences, Engineering, and Medicine, 760 "Quantum Computing: Progress and Prospects", The National 761 Academies Press, DOI 10.17226/25196, 2019. 763 [S1994] Shor, P., "Algorithms for Quantum Computation: Discrete 764 Logarithms and Factoring", Proceedings of the 35th Annual 765 Symposium on Foundations of Computer Science, 1994, pp. 766 124-134. 768 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 769 RFC 2631, June 1999. 771 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 772 "Randomness Requirements for Security", RFC 4086, 773 June 2005. 775 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 776 Housley, R., and W. Polk, "Internet X.509 Public Key 777 Infrastructure Certificate and Certificate Revocation List 778 (CRL) Profile", RFC 5280, May 2008. 780 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 781 Cryptography (ECC) Algorithms in Cryptographic Message 782 Syntax (CMS)", RFC 5753, January 2010. 784 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 785 Expand Key Derivation Function (HKDF)", RFC 5869, 786 May 2010. 788 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 789 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 790 June 2010. 792 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 793 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 794 June 2010. 796 [RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for 797 the Cryptographic Message Syntax (CMS) and the Public Key 798 Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011. 800 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 801 "PKCS #1: RSA Cryptography Specifications Version 2.2", 802 RFC 8017, November 2016. 804 Appendix A: Key Transport with PSK Example 806 This example shows the establishment of an AES-256 content-encryption 807 key using: 808 - a pre-shared key of 256 bits; 809 - key transport using RSA PKCS#1 v1.5 with a 3072-bit key; 810 - key derivation using HKDF with SHA-384; and 811 - key wrap using AES-256-KEYWRAP. 813 In real-world use, the originator would encrypt the key-derivation 814 key in their own RSA public key as well as the recipient's public 815 key. This is omitted in an attempt to simplify the example. 817 A.1. Originator Processing Example 819 The pre-shared key known to Alice and Bob: 820 c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 822 The identifier assigned to the pre-shared key is: 823 ptf-kmc:13614122112 825 Alice obtains Bob's public key: 826 -----BEGIN PUBLIC KEY----- 827 MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ 828 AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH 829 Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq 830 vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx 831 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v 832 SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a 833 uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy 834 FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS 835 whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= 836 -----END PUBLIC KEY----- 838 Bob's RSA public key has the following key identifier: 839 9eeb67c9b95a74d44d2f16396680e801b5cba49c 841 Alice randomly generates a content-encryption key: 842 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 844 Alice randomly generates a key-derivation key: 845 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 847 Alice encrypts the key-derivation key in Bob's public key: 848 4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d 849 8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01 850 48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626 851 74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7 852 667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80 853 6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3 854 b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a 855 2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a 856 59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710 857 1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85 858 d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077 859 63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53 861 Alice produces a 256-bit key-encryption key with HKDF using SHA-384; 862 the secret value is the key-derivation key; the 'info' is the DER- 863 encoded CMSORIforPSKOtherInfo structure with the following values: 864 0 56: SEQUENCE { 865 2 32: OCTET STRING 866 : C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB 867 : 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15 868 36 1: ENUMERATED 5 869 39 11: SEQUENCE { 870 41 9: OBJECT IDENTIFIER aes256-wrap 871 : { 2 16 840 1 101 3 4 1 45 } 872 : } 873 52 1: INTEGER 32 874 55 1: INTEGER 32 875 : } 877 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 878 30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336 879 5cf95b150a0105300b060960864801650304012d020120020120 881 The HKDF output is 256 bits: 882 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 884 Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption 885 key with the key-encryption key: 886 ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 887 c83d0dd5d1b4faa5 889 Alice encrypts the content using AES-256-GCM with the content- 890 encryption key. The 12-octet nonce used is: 891 cafebabefacedbaddecaf888 893 The content plaintext is: 894 48656c6c6f2c20776f726c6421 896 The resulting ciphertext is: 897 9af2d16f21547fcefed9b3ef2d 899 The resulting 12-octet authentication tag is: 900 a0e5925cc184e0172463c44c 902 A.2. ContentInfo and AuthEnvelopedData 904 Alice encodes the AuthEnvelopedData and the ContentInfo, and 905 sends the result to Bob. The resulting structure is: 907 0 650: SEQUENCE { 908 4 11: OBJECT IDENTIFIER authEnvelopedData 909 : { 1 2 840 113549 1 9 16 1 23 } 910 17 633: [0] { 911 21 629: SEQUENCE { 912 25 1: INTEGER 0 913 28 551: SET { 914 32 547: [4] { 915 36 11: OBJECT IDENTIFIER ** Placeholder ** 916 : { 1 2 840 113549 1 9 16 TBD 1 } 917 49 530: SEQUENCE { 918 53 1: INTEGER 0 919 56 19: OCTET STRING 'ptf-kmc:13614122112' 920 77 13: SEQUENCE { 921 79 11: OBJECT IDENTIFIER ** Placeholder ** 922 : { 1 2 840 113549 1 9 16 3 TBD } 923 : } 924 92 11: SEQUENCE { 925 94 9: OBJECT IDENTIFIER aes256-wrap 926 : { 2 16 840 1 101 3 4 1 45 } 927 : } 928 105 432: SEQUENCE { 929 109 428: SEQUENCE { 930 113 1: INTEGER 2 931 116 20: [0] 932 : 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01 933 : B5 CB A4 9C 934 138 13: SEQUENCE { 935 140 9: OBJECT IDENTIFIER rsaEncryption 936 : { 1 2 840 113549 1 1 1 } 937 151 0: NULL 938 : } 939 153 384: OCTET STRING 940 : 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A 941 : 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5 942 : 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3 943 : A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B 944 : 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C 945 : 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B 946 : FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B 947 : 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92 948 : 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77 949 : FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E 950 : 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 951 : 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2 952 : AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20 953 : 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7 954 : EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76 955 : 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA 956 : 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28 957 : 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66 958 : 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC 959 : 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F 960 : 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A 961 : 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 962 : 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C 963 : B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF 5B 5D 964 : } 965 : } 966 541 40: OCTET STRING 967 : AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7 968 : 15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66 969 : C8 3D 0D D5 D1 B4 FA A5 970 : } 971 : } 972 : } 973 583 55: SEQUENCE { 974 585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 975 596 27: SEQUENCE { 976 598 9: OBJECT IDENTIFIER aes256-GCM 977 : { 2 16 840 1 101 3 4 1 46 } 978 609 14: SEQUENCE { 979 611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88 980 : } 981 : } 982 625 13: [0] 9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D 983 : } 984 640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C 985 : } 986 : } 987 : } 989 A.3. Recipient Processing Example 991 Bob's private key: 992 -----BEGIN RSA PRIVATE KEY----- 993 MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx 994 WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su 995 sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro 996 ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q 997 khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b 998 JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW 999 MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn 1000 XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd 1001 ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x 1002 jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV 1003 3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh 1004 9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs 1005 Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK 1006 q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX 1007 UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk 1008 HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7 1009 8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq 1010 haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J 1011 fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu 1012 oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh 1013 /QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q 1014 DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1 1015 0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96 1016 W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy 1017 mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4 1018 mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I 1019 SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ 1020 B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 1021 gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr 1022 ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI 1023 x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T 1024 UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ 1025 SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz 1026 AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x 1027 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 1028 sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f 1029 hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== 1030 -----END RSA PRIVATE KEY----- 1032 Bob decrypts the key-derivation key with his RSA private key: 1033 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 1035 Bob produces a 256-bit key-encryption key with HKDF using SHA-384; 1036 the secret value is the key-derivation key; the 'info' is the DER- 1037 encoded CMSORIforPSKOtherInfo structure with the same values as 1038 shown in A.1. The HKDF output is 256 bits: 1039 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 1041 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1042 with the key-encryption key; the content-encryption key is: 1043 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 1045 Bob decrypts the content using AES-256-GCM with the content- 1046 encryption key, and checks the received authentication tag. The 1047 12-octet nonce used is: 1048 cafebabefacedbaddecaf888 1050 The 12-octet authentication tag is: 1051 a0e5925cc184e0172463c44c 1053 The received ciphertext content is: 1054 9af2d16f21547fcefed9b3ef2d 1056 The resulting plaintext content is: 1057 48656c6c6f2c20776f726c6421 1059 Appendix B: Key Agreement with PSK Example 1061 This example shows the establishment of an AES-256 content-encryption 1062 key using: 1063 - a pre-shared key of 256 bits; 1064 - key agreement using ECDH on curve P-384 and X9.63 KDF 1065 with SHA-384; 1066 - key derivation using HKDF with SHA-384; and 1067 - key wrap using AES-256-KEYWRAP. 1069 In real-world use, the originator would treat themselves as an 1070 additional recipient by performing key agreement with their own 1071 static public key and the ephemeral private key generated for this 1072 message. This is omitted in an attempt to simplify the example. 1074 B.1. Originator Processing Example 1076 The pre-shared key known to Alice and Bob: 1077 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 1079 The identifier assigned to the pre-shared key is: 1080 ptf-kmc:216840110121 1082 Alice randomly generates a content-encryption key: 1083 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1085 Alice obtains Bob's static ECDH public key: 1086 -----BEGIN PUBLIC KEY----- 1087 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY 1088 /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM 1089 YkcpxMGo32z3JetEloW5aFOja13vv/W5 1090 -----END PUBLIC KEY----- 1092 It has a key identifier of: 1093 e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 1095 Alice generates an ephemeral ECDH key pair on the same curve: 1096 -----BEGIN EC PRIVATE KEY----- 1097 MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp 1098 /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA 1099 LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb 1100 GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8= 1101 -----END EC PRIVATE KEY----- 1103 Alice computes a shared secret, called Z, using the Bob's static 1104 ECDH public key and her ephemeral ECDH private key; Z is: 1105 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1106 19cf8807e6d800c2de40240fe0e26adc 1108 Alice computes the pairwise key-encryption key, called KEK1, from Z 1109 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1110 following values: 1111 0 21: SEQUENCE { 1112 2 11: SEQUENCE { 1113 4 9: OBJECT IDENTIFIER aes256-wrap 1114 : { 2 16 840 1 101 3 4 1 45 } 1115 : } 1116 15 6: [2] { 1117 17 4: OCTET STRING 00 00 00 20 1118 : } 1119 : } 1121 The DER encoding of ECC-CMS-SharedInfo produces 23 octets: 1122 3015300b060960864801650304012da206040400000020 1124 The X9.63 KDF output is the 256-bit KEK1: 1125 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1127 Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1128 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1129 structure with the following values: 1130 0 56: SEQUENCE { 1131 2 32: OCTET STRING 1132 : 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F 1133 : A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4 1134 36 1: ENUMERATED 10 1135 39 11: SEQUENCE { 1136 41 9: OBJECT IDENTIFIER aes256-wrap 1137 : { 2 16 840 1 101 3 4 1 45 } 1138 : } 1139 52 1: INTEGER 32 1140 55 1: INTEGER 32 1141 : } 1143 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 1144 303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021 1145 4e2d83e40a010a300b060960864801650304012d020120020120 1147 The HKDF output is the 256-bit KEK2: 1148 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1150 Alice uses AES-KEY-WRAP to encrypt the content-encryption key 1151 with the KEK2; the wrapped key is: 1152 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b 1153 de08866a602d63f4 1155 Alice encrypts the content using AES-256-GCM with the content- 1156 encryption key. The 12-octet nonce used is: 1157 dbaddecaf888cafebabeface 1159 The plaintext is: 1160 48656c6c6f2c20776f726c6421 1162 The resulting ciphertext is: 1163 fc6d6f823e3ed2d209d0c6ffcf 1165 The resulting 12-octet authentication tag is: 1166 550260c42e5b29719426c1ff 1168 B.2. ContentInfo and AuthEnvelopedData 1170 Alice encodes the AuthEnvelopedData and the ContentInfo, and 1171 sends the result to Bob. The resulting structure is: 1173 0 327: SEQUENCE { 1174 4 11: OBJECT IDENTIFIER authEnvelopedData 1175 : { 1 2 840 113549 1 9 16 1 23 } 1176 17 310: [0] { 1177 21 306: SEQUENCE { 1178 25 1: INTEGER 0 1179 28 229: SET { 1180 31 226: [4] { 1181 34 11: OBJECT IDENTIFIER ** Placeholder ** 1182 : { 1 2 840 113549 1 9 16 TBD 2 } 1183 47 210: SEQUENCE { 1184 50 1: INTEGER 0 1185 53 20: OCTET STRING 'ptf-kmc:216840110121' 1186 75 85: [0] { 1187 77 83: [1] { 1188 79 19: SEQUENCE { 1189 81 6: OBJECT IDENTIFIER 1190 : dhSinglePass-stdDH-sha256kdf-scheme 1191 : { 1 3 132 1 11 1 } 1192 89 9: OBJECT IDENTIFIER aes256-wrap 1193 : { 2 16 840 1 101 3 4 1 45 } 1194 : } 1195 100 60: BIT STRING, encapsulates { 1196 103 57: OCTET STRING 1197 : 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD 1198 : 4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA 1199 : FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30 1200 : E0 D2 9C B6 89 0A 36 0A 6C 1201 : } 1202 : } 1203 : } 1204 162 13: SEQUENCE { 1205 164 11: OBJECT IDENTIFIER ** Placeholder ** 1206 : { 1 2 840 113549 1 9 16 3 TBD } 1207 : } 1208 177 11: SEQUENCE { 1209 179 9: OBJECT IDENTIFIER aes256-wrap 1210 : { 2 16 840 1 101 3 4 1 45 } 1211 : } 1212 190 68: SEQUENCE { 1213 192 66: SEQUENCE { 1214 194 22: [0] { 1215 196 20: OCTET STRING 1216 : E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC 1217 : DC 05 C5 29 1218 : } 1219 218 40: OCTET STRING 1220 : 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB 1221 : 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B 1222 : DE 08 86 6A 60 2D 63 F4 1223 : } 1224 : } 1225 : } 1226 : } 1227 : } 1228 260 55: SEQUENCE { 1229 262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 1230 273 27: SEQUENCE { 1231 275 9: OBJECT IDENTIFIER aes256-GCM 1232 : { 2 16 840 1 101 3 4 1 46 } 1233 286 14: SEQUENCE { 1234 288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE 1235 : } 1236 : } 1237 302 13: [0] FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF 1238 : } 1239 317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF 1240 : } 1241 : } 1242 : } 1244 B.3. Recipient Processing Example 1246 Bob obtains Alice's ephemeral ECDH public key from the message: 1247 -----BEGIN PUBLIC KEY----- 1248 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV 1249 wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT 1250 2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v 1251 -----END PUBLIC KEY----- 1253 Bob's static ECDH private key: 1254 -----BEGIN EC PRIVATE KEY----- 1255 MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk 1256 NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9 1257 149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi 1258 RynEwajfbPcl60SWhbloU6NrXe+/9bk= 1259 -----END EC PRIVATE KEY----- 1261 Bob computes a shared secret, called Z, using the Alice's ephemeral 1262 ECDH public key and his static ECDH private key; Z is: 1263 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1264 19cf8807e6d800c2de40240fe0e26adc 1266 Bob computes the pairwise key-encryption key, called KEK1, from Z 1267 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1268 values shown in B.1. The X9.63 KDF output is the 256-bit KEK1: 1269 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1271 Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1272 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1273 structure with the values shown in B.1. The HKDF output is the 1274 256-bit KEK2: 1275 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1277 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1278 with the KEK2; the content-encryption key is: 1279 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1281 Bob decrypts the content using AES-256-GCM with the content- 1282 encryption key, and checks the received authentication tag. The 1283 12-octet nonce used is: 1284 dbaddecaf888cafebabeface 1286 The 12-octet authentication tag is: 1287 550260c42e5b29719426c1ff 1289 The received ciphertext content is: 1290 fc6d6f823e3ed2d209d0c6ffcf 1292 The resulting plaintext content is: 1293 48656c6c6f2c20776f726c6421 1295 Acknowledgements 1297 Many thanks to Roman Danyliw, Burt Kaliski, Panos Kampanakis, Jim 1298 Schaad, Robert Sparks, Sean Turner, and Daniel Van Geest for their 1299 review and insightful comments. They have greatly improved the 1300 design, clarity, and implementation guidance. 1302 Author's Address 1304 Russ Housley 1305 Vigil Security, LLC 1306 516 Dranesville Road 1307 Herndon, VA 20170 1308 USA 1309 EMail: housley@vigilsec.com