idnits 2.17.00 (12 Aug 2021) /tmp/idnits55791/draft-ietf-lamps-cms-mix-with-psk-07.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 (23 August 2019) is 995 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 1294 -- Looks like a reference, but probably isn't: '1' on line 1244 -- Looks like a reference, but probably isn't: '4' on line 1237 -- Looks like a reference, but probably isn't: '2' on line 1173 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 6268 -- 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-05 == Outdated reference: draft-ietf-lamps-cms-mix-with-psk has been published as RFC 8696 Summary: 2 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: 23 February 2020 23 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. It 191 is best if each PSK has a unique identifier; however, if a recipient 192 has more than one PSK with the same identifier, the recipient can try 193 each of them in turn. A PSK is expected to be used with many 194 messages, with a lifetime of weeks or months. 196 The content-encryption key or content-authenticated-encryption key is 197 quantum-resistant, and the sender establishes it using these steps: 199 When using a key transport algorithm: 201 1. The content-encryption key or the content-authenticated- 202 encryption key, called CEK, is generated at random. 204 2. The key-derivation key, called KDK, is generated at random. 206 3. For each recipient, the KDK is encrypted in the recipient's 207 public key, then the key derivation function (KDF) is used to 208 mix the pre-shared key (PSK) and the KDK to produce the key- 209 encryption key, called KEK. 211 4. The KEK is used to encrypt the CEK. 213 When using a key agreement algorithm: 215 1. The content-encryption key or the content-authenticated- 216 encryption key, called CEK, is generated at random. 218 2. For each recipient, a pairwise key-encryption key, called KEK1, 219 is established using the recipient's public key and the 220 sender's private key. Note that KEK1 will be used as a key- 221 derivation key. 223 3. For each recipient, the key derivation function (KDF) is used 224 to mix the pre-shared key (PSK) and the pairwise KEK1, and the 225 result is called KEK2. 227 4. For each recipient, the pairwise KEK2 is used to encrypt the 228 CEK. 230 As specified in Section 6.2.5 of [RFC5652], recipient information for 231 additional key management techniques are represented in the 232 OtherRecipientInfo type. Two key management techniques are specified 233 in this document, and they are each identified by a unique ASN.1 234 object identifier. 236 The first key management technique, called keyTransPSK, see 237 Section 3, uses a key transport algorithm to transfer the key- 238 derivation key from the sender to the recipient, and then the key- 239 derivation key is mixed with the PSK using a KDF. The output of the 240 KDF is the key-encryption key, which is used for the encryption of 241 the content-encryption key or content-authenticated-encryption key. 243 The second key management technique, called keyAgreePSK, see 244 Section 4, uses a key agreement algorithm to establish a pairwise 245 key-encryption key, which is then mixed with the PSK using a KDF to 246 produce a second pairwise key-encryption key, which is then used to 247 encrypt the content-encryption key or content-authenticated- 248 encryption key. 250 3. keyTransPSK 252 Per-recipient information using keyTransPSK is represented in the 253 KeyTransPSKRecipientInfo type, which is indicated by the id-ori- 254 keyTransPSK object identifier. Each instance of 255 KeyTransPSKRecipientInfo establishes the content-encryption key or 256 content-authenticated-encryption key for one or more recipients that 257 have access to the same PSK. 259 The id-ori-keyTransPSK object identifier is: 261 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 262 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 264 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 266 The KeyTransPSKRecipientInfo type is: 268 KeyTransPSKRecipientInfo ::= SEQUENCE { 269 version CMSVersion, -- always set to 0 270 pskid PreSharedKeyIdentifier, 271 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 272 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 273 ktris KeyTransRecipientInfos, 274 encryptedKey EncryptedKey } 276 PreSharedKeyIdentifier ::= OCTET STRING 278 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 280 The fields of the KeyTransPSKRecipientInfo type have the following 281 meanings: 283 version is the syntax version number. The version MUST be 0. The 284 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 286 pskid is the identifier of the PSK used by the sender. The 287 identifier is an OCTET STRING, and it need not be human readable. 289 kdfAlgorithm identifies the key-derivation algorithm, and any 290 associated parameters, used by the sender to mix the key- 291 derivation key and the PSK to generate the key-encryption key. 292 The KeyDerivationAlgorithmIdentifier is described in Section 293 10.1.6 of [RFC5652]. 295 keyEncryptionAlgorithm identifies a key-encryption algorithm used 296 to encrypt the content-encryption key. The 297 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 298 [RFC5652]. 300 ktris contains one KeyTransRecipientInfo type for each recipient; 301 it uses a key transport algorithm to establish the key-derivation 302 key. That is, the encryptedKey field of KeyTransRecipientInfo 303 contains the key-derivation key instead of the content-encryption 304 key. KeyTransRecipientInfo is described in Section 6.2.1 of 305 [RFC5652]. 307 encryptedKey is the result of encrypting the content-encryption 308 key or the content-authenticated-encryption key with the key- 309 encryption key. EncryptedKey is an OCTET STRING. 311 4. keyAgreePSK 313 Per-recipient information using keyAgreePSK is represented in the 314 KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- 315 keyAgreePSK object identifier. Each instance of 316 KeyAgreePSKRecipientInfo establishes the content-encryption key or 317 content-authenticated-encryption key for one or more recipients that 318 have access to the same PSK. 320 The id-ori-keyAgreePSK object identifier is: 322 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 324 The KeyAgreePSKRecipientInfo type is: 326 KeyAgreePSKRecipientInfo ::= SEQUENCE { 327 version CMSVersion, -- always set to 0 328 pskid PreSharedKeyIdentifier, 329 originator [0] EXPLICIT OriginatorIdentifierOrKey, 330 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 331 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 332 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 333 recipientEncryptedKeys RecipientEncryptedKeys } 335 The fields of the KeyAgreePSKRecipientInfo type have the following 336 meanings: 338 version is the syntax version number. The version MUST be 0. The 339 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 341 pskid is the identifier of the PSK used by the sender. The 342 identifier is an OCTET STRING, and it need not be human readable. 344 originator is a CHOICE with three alternatives specifying the 345 sender's key agreement public key. Implementations MUST support 346 all three alternatives for specifying the sender's public key. 347 The sender uses their own private key and the recipient's public 348 key to generate a pairwise key-encryption key. A key derivation 349 function (KDF) is used to mix the PSK and the pairwise key- 350 encryption key to produce a second key-encryption key. The 351 OriginatorIdentifierOrKey type is described in Section 6.2.2 of 352 [RFC5652]. 354 ukm is optional. With some key agreement algorithms, the sender 355 provides a User Keying Material (UKM) to ensure that a different 356 key is generated each time the same two parties generate a 357 pairwise key. Implementations MUST accept a 358 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 359 Implementations that do not support key agreement algorithms that 360 make use of UKMs MUST gracefully handle the presence of UKMs. The 361 UserKeyingMaterial type is described in Section 10.2.6 of 362 [RFC5652]. 364 kdfAlgorithm identifies the key-derivation algorithm, and any 365 associated parameters, used by the sender to mix the pairwise key- 366 encryption key and the PSK to produce a second key-encryption key 367 of the same length as the first one. The 368 KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of 369 [RFC5652]. 371 keyEncryptionAlgorithm identifies a key-encryption algorithm used 372 to encrypt the content-encryption key or the content- 373 authenticated-encryption key. The 374 KeyEncryptionAlgorithmIdentifier type is described in Section 375 10.1.3 of [RFC5652]. 377 recipientEncryptedKeys includes a recipient identifier and 378 encrypted key for one or more recipients. The 379 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 380 specifying the recipient's certificate, and thereby the 381 recipient's public key, that was used by the sender to generate a 382 pairwise key-encryption key. The encryptedKey is the result of 383 encrypting the content-encryption key or the content- 384 authenticated-encryption key with the second pairwise key- 385 encryption key. EncryptedKey is an OCTET STRING. The 386 RecipientEncryptedKeys type is defined in Section 6.2.2 of 387 [RFC5652]. 389 5. Key Derivation 391 Many key derivation functions (KDFs) internally employ a one-way hash 392 function. When this is the case, the hash function that is used is 393 indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF 394 [RFC5869] is one example of a KDF that makes use of a hash function. 396 Other KDFs internally employ an encryption algorithm. When this is 397 the case, the encryption that is used is indirectly indicated by the 398 KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be 399 used for randomness extraction in a KDF as described in [NIST2018]. 401 A KDF has several input values. This section describes the 402 conventions for using the KDF to compute the key-encryption key for 403 KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For 404 simplicity, the terminology used in the HKDF [RFC5869] specification 405 is used here. 407 The KDF inputs are: 409 IKM is the input keying material; it is the symmetric secret input 410 to the KDF. For KeyTransPSKRecipientInfo, it is the key- 411 derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise 412 key-encryption key produced by the key agreement algorithm. 414 salt is an optional non-secret random value. Many KDFs do not 415 require a salt, and the KeyDerivationAlgorithmIdentifier 416 assignments for HKDF [RFC8619] do not offer a parameter for a 417 salt. If a particular KDF requires a salt, then the salt value is 418 provided as a parameter of the KeyDerivationAlgorithmIdentifier. 420 L is the length of output keying material in octets; the value 421 depends on the key-encryption algorithm that will be used. The 422 algorithm is identified by the KeyEncryptionAlgorithmIdentifier. 423 In addition, the OBJECT IDENTIFIER portion of the 424 KeyEncryptionAlgorithmIdentifier is included in the next input 425 value, called info. 427 info is optional context and application specific information. 428 The DER-encoding of CMSORIforPSKOtherInfo is used as the info 429 value, and the PSK is included in this structure. Note that 430 EXPLICIT tagging is used in the ASN.1 module that defines this 431 structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of 432 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 433 10 is used. CMSORIforPSKOtherInfo is defined by the following 434 ASN.1 structure: 436 CMSORIforPSKOtherInfo ::= SEQUENCE { 437 psk OCTET STRING, 438 keyMgmtAlgType ENUMERATED { 439 keyTrans (5), 440 keyAgree (10) }, 441 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 442 pskLength INTEGER (1..MAX), 443 kdkLength INTEGER (1..MAX) } 445 The fields of type CMSORIforPSKOtherInfo have the following meanings: 447 psk is an OCTET STRING; it contains the PSK. 449 keyMgmtAlgType is either set to 5 or 10. For 450 KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For 451 KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. 453 keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, 454 which identifies the algorithm and provides algorithm parameters, 455 if any. 457 pskLength is a positive integer; it contains the length of the PSK 458 in octets. 460 kdkLength is a positive integer; it contains the length of the 461 key-derivation key in octets. For KeyTransPSKRecipientInfo, the 462 key-derivation key is generated by the sender. For 463 KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise 464 key-encryption key produced by the key agreement algorithm. 466 The KDF output is: 468 OKM is the output keying material, which is exactly L octets. The 469 OKM is the key-encryption key that is used to encrypt the content- 470 encryption key or the content-authenticated-encryption key. 472 An acceptable KDF MUST accept IKM, L, and info inputs; and acceptable 473 KDF MAY also accept salt and other inputs. All of these inputs MUST 474 influence the output of the KDF. If the KDF requires a salt or other 475 inputs, then those inputs MUST be provided as parameters of the 476 KeyDerivationAlgorithmIdentifier. 478 6. ASN.1 Module 480 This section contains the ASN.1 module for the two key management 481 techniques defined in this document. This module imports types from 482 other ASN.1 modules that are defined in [RFC5912] and [RFC6268]. 484 486 CMSORIforPSK-2019 487 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 488 smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) } 490 DEFINITIONS EXPLICIT TAGS ::= 491 BEGIN 493 -- EXPORTS All 495 IMPORTS 497 AlgorithmIdentifier{}, KEY-DERIVATION 498 FROM AlgorithmInformation-2009 -- [RFC5912] 499 { iso(1) identified-organization(3) dod(6) internet(1) 500 security(5) mechanisms(5) pkix(7) id-mod(0) 501 id-mod-algorithmInformation-02(58) } 503 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 504 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 505 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 506 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 507 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 508 { iso(1) member-body(2) us(840) rsadsi(113549) 509 pkcs(1) pkcs-9(9) smime(16) modules(0) 510 id-mod-cms-2009(58) } ; 512 -- 513 -- OtherRecipientInfo Types (ori-) 514 -- 516 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 517 ori-keyTransPSK | 518 ori-keyAgreePSK, 519 ... } 521 -- 522 -- Key Transport with Pre-Shared Key 523 -- 525 ori-keyTransPSK OTHER-RECIPIENT ::= { 526 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 528 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 529 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 531 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 533 KeyTransPSKRecipientInfo ::= SEQUENCE { 534 version CMSVersion, -- always set to 0 535 pskid PreSharedKeyIdentifier, 536 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 537 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 538 ktris KeyTransRecipientInfos, 539 encryptedKey EncryptedKey } 541 PreSharedKeyIdentifier ::= OCTET STRING 543 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 545 -- 546 -- Key Agreement with Pre-Shared Key 547 -- 549 ori-keyAgreePSK OTHER-RECIPIENT ::= { 550 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 552 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 553 KeyAgreePSKRecipientInfo ::= SEQUENCE { 554 version CMSVersion, -- always set to 0 555 pskid PreSharedKeyIdentifier, 556 originator [0] EXPLICIT OriginatorIdentifierOrKey, 557 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 558 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 559 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 560 recipientEncryptedKeys RecipientEncryptedKeys } 562 -- 563 -- Structure to provide 'info' input to the KDF, 564 -- including the Pre-Shared Key 565 -- 567 CMSORIforPSKOtherInfo ::= SEQUENCE { 568 psk OCTET STRING, 569 keyMgmtAlgType ENUMERATED { 570 keyTrans (5), 571 keyAgree (10) }, 572 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 573 pskLength INTEGER (1..MAX), 574 kdkLength INTEGER (1..MAX) } 576 END 578 580 7. Security Considerations 582 The security considerations in related to the CMS enveloped-data 583 content type in [RFC5652] and the security considerations related to 584 the CMS authenticated-enveloped-data content type in [RFC5083] 585 continue to apply. 587 Implementations of the key derivation function must compute the 588 entire result, which in this specification is a key-encryption key, 589 before outputting any portion of the result. The resulting key- 590 encryption key must be protected. Compromise of the key-encryption 591 key may result in the disclosure of all content-encryption keys or 592 content-authenticated-encryption keys that were protected with that 593 keying material, which in turn may result in the disclosure of the 594 content. Note that there are two key-encryption keys when a PSK with 595 a key agreement algorithm is used, with similar consequence for the 596 compromise of either one of these keys. 598 Implementations must protect the pre-shared key (PSK), key transport 599 private key, the agreement private key, and the key-derivation key. 600 Compromise of the PSK will make the encrypted content vulnerable to 601 the future invention of a large-scale quantum computer. Compromise 602 of the PSK and either the key transport private key or the agreement 603 private key may result in the disclosure of all contents protected 604 with that combination of keying material. Compromise of the PSK and 605 the key-derivation key may result in disclosure of all contents 606 protected with that combination of keying material. 608 A large-scale quantum computer will essentially negate the security 609 provided by the key transport algorithm or the key agreement 610 algorithm, which means that the attacker with a large-scale quantum 611 computer can discover the key-derivation key. In addition a large- 612 scale quantum computer effectively cuts the security provided by a 613 symmetric key algorithm in half. Therefore, the PSK needs at least 614 256 bits of entropy to provide 128 bits of security. To match that 615 same level of security, the key derivation function needs to be 616 quantum-resistant and produce a key-encryption key that is at least 617 256 bits in length. Similarly, the content-encryption key or 618 content-authenticated-encryption key needs to be at least 256 bits in 619 length. 621 When using a PSK with a key transport or a key agreement algorithm, a 622 key-encryption key is produced to encrypt the content-encryption key 623 or content-authenticated-encryption key. If the key-encryption 624 algorithm is different than the algorithm used to protect the 625 content, then the effective security is determined by the weaker of 626 the two algorithms. If, for example, content is encrypted with 627 256-bit AES, and the key is wrapped with 128-bit AES, then at most 628 128 bits of protection is provided. Implementers must ensure that 629 the key-encryption algorithm is as strong or stronger than the 630 content-encryption algorithm or content-authenticated-encryption 631 algorithm. 633 The selection of the key-derivation function imposes an upper bound 634 on the strength of the resulting key-encryption key. The strength of 635 the selected key-derivation function should be at least as strong as 636 the key-encryption algorithm that is selected. NIST SP 800-56C 637 Revision 1 [NIST2018] offers advice on the security strength of 638 several popular key-derivation functions. 640 Implementers should not mix quantum-resistant key management 641 algorithms with their non-quantum-resistant counterparts. For 642 example, the same content should not be protected with 643 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 644 same content should not be protected with KeyAgreeRecipientInfo and 645 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 646 to the future invention of a large-scale quantum computer. 648 Implementers should not send the same content in different messages, 649 one using a quantum-resistant key management algorithm and the other 650 using a non-quantum-resistant key management algorithm, even if the 651 content-encryption key is generated independently. Doing so may 652 allow an eavesdropper to correlate the messages, making the content 653 vulnerable to the future invention of a large-scale quantum computer. 655 This specification does not require that PSK is known only by the 656 sender and recipients. The PSK may be known to a group. Since 657 confidentiality depends on the key transport or key agreement 658 algorithm, knowledge of the PSK by other parties does not enable 659 inherently eavesdropping. However, group members can record the 660 traffic of other members, and then decrypt it if they ever gain 661 access to a large-scale quantum computer. Also, when many parties 662 know the PSK, there are many opportunities for theft of the PSK by an 663 attacker. Once an attacker has the PSK, they can decrypt stored 664 traffic if they ever gain access to a large-scale quantum computer in 665 the same manner as a legitimate group member. 667 Sound cryptographic key hygiene is to use a key for one and only one 668 purpose. Use of the recipient's public key for both the traditional 669 CMS and the PSK-mixing variation specified in this document would be 670 a violation of this principle; however, there is no known way for an 671 attacker to take advantage of this situation. That said, an 672 application should enforce separation whenever possible. For 673 example, a purpose identifier for use in the X.509 extended key usage 674 certificate extension [RFC5280] could be identified in the future to 675 indicate that a public key should only be used in conjunction with a 676 PSK, or only without. 678 Implementations must randomly generate key-derivation keys as well as 679 the content-encryption keys or content-authenticated-encryption keys. 680 Also, the generation of public/private key pairs for the key 681 transport and key agreement algorithms rely on a random numbers. The 682 use of inadequate pseudo-random number generators (PRNGs) to generate 683 cryptographic keys can result in little or no security. An attacker 684 may find it much easier to reproduce the PRNG environment that 685 produced the keys, searching the resulting small set of 686 possibilities, rather than brute force searching the whole key space. 687 The generation of quality random numbers is difficult. [RFC4086] 688 offers important guidance in this area. 690 Implementers should be aware that cryptographic algorithms become 691 weaker with time. As new cryptanalysis techniques are developed and 692 computing performance improves, the work factor to break a particular 693 cryptographic algorithm will be reduced. Therefore, cryptographic 694 algorithm implementations should be modular, allowing new algorithms 695 to be readily inserted. That is, implementers should be prepared for 696 the set of supported algorithms to change over time. 698 The security properties provided by the mechanisms specified in this 699 document can be validated using formal methods. A ProVerif proof in 700 [H2019] shows that an attacker with a large-scale quantum computer 701 that is capable of breaking the Diffie-Hellman key agreement 702 algorithm cannot disrupt the delivery of the content-encryption key 703 to the recipient and the attacker cannot learn the content-encryption 704 key from the protocol exchange. 706 8. Privacy Considerations 708 An observer can see which parties are using each PSK simply by 709 watching the PSK key identifiers. However, the addition of these key 710 identifiers is not really making privacy worse. When key transport 711 is used, the RecipientIdentifier is always present, and it clearly 712 identifies each recipient to an observer. When key agreement is 713 used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier 714 is always present, and these clearly identify each recipient. 716 9. IANA Considerations 718 One object identifier for the ASN.1 module in Section 6 was assigned 719 in the SMI Security for S/MIME Module Identifiers 720 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 722 id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { 723 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 724 pkcs-9(9) smime(16) mod(0) TBD0 } 726 One new registry was created for Other Recipient Info Identifiers 727 within the SMI Security for S/MIME Mail Security 728 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 730 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 731 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 733 Updates to the new registry are to be made according to the 734 Specification Required policy as defined in [RFC8126]. The expert is 735 expected to ensure that any new values identify additions 736 RecipientInfo structures for use with the CMS. Object identifiers 737 for other purposes should not be assigned in this arc. 739 Two assignments were made in the new SMI Security for Other Recipient 740 Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry 741 with references to this document: 743 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 744 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 745 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 747 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 748 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 749 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 751 10. References 753 10.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 759 Authenticated-Enveloped-Data Content Type", RFC 5083, 760 November 2007. 762 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 763 5652, September 2009. 765 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 766 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 767 June 2010. 769 [RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for 770 the Cryptographic Message Syntax (CMS) and the Public Key 771 Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011. 773 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 774 Writing an IANA Considerations Section in RFCs", BCP 26, 775 RFC 8126, June 2017. 777 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 778 2119 Key Words", BCP 14, RFC 8174, May 2017. 780 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 781 One (ASN.1): Specification of basic notation", ITU-T 782 Recommendation X.680, 2015. 784 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 785 Specification of Basic Encoding Rules (BER), Canonical 786 Encoding Rules (CER) and Distinguished Encoding Rules 787 (DER)", ITU-T Recommendation X.690, 2015. 789 10.2. Informative References 791 [AES] National Institute of Standards and Technology, FIPS Pub 792 197: Advanced Encryption Standard (AES), 26 November 2001. 794 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 795 Quantum Cryptography", work-in-progress, draft-hoffman- 796 c2pq-05, August 2018. 798 [FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A 799 kilobit hidden SNFS discrete logarithm computation", 800 Cryptology ePrint Archive, Report 2016/961, 2016. 801 https://eprint.iacr.org/2016/961.pdf. 803 [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- 804 lamps-cms-mix-with-psk", , 27 May 2019. 807 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 808 numbers.xhtml#security-smime-0. 810 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 811 numbers.xhtml#security-smime. 813 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 814 numbers.xhtml#security-smime-TBD1. 816 [NAS2019] National Academies of Sciences, Engineering, and Medicine, 817 "Quantum Computing: Progress and Prospects", The National 818 Academies Press, DOI 10.17226/25196, 2019. 820 [NIST2018] Barker, E., Chen, L., and R. Davis, "Recommendation for 821 Key-Derivation Methods in Key-Establishment Schemes", 822 NIST Special Publication 800-56C Rev. 1, April 2018, 823 . 826 [S1994] Shor, P., "Algorithms for Quantum Computation: Discrete 827 Logarithms and Factoring", Proceedings of the 35th Annual 828 Symposium on Foundations of Computer Science, 1994, pp. 829 124-134. 831 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 832 RFC 2631, June 1999. 834 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 835 "Randomness Requirements for Security", RFC 4086, 836 June 2005. 838 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 839 Housley, R., and W. Polk, "Internet X.509 Public Key 840 Infrastructure Certificate and Certificate Revocation List 841 (CRL) Profile", RFC 5280, May 2008. 843 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 844 Cryptography (ECC) Algorithms in Cryptographic Message 845 Syntax (CMS)", RFC 5753, January 2010. 847 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 848 Expand Key Derivation Function (HKDF)", RFC 5869, 849 May 2010. 851 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 852 "PKCS #1: RSA Cryptography Specifications Version 2.2", 853 RFC 8017, November 2016. 855 [RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based 856 Extract-and-Expand Key Derivation Function (HKDF)", June 857 2019. 859 Appendix A: Key Transport with PSK Example 861 This example shows the establishment of an AES-256 content-encryption 862 key using: 863 - a pre-shared key of 256 bits; 864 - key transport using RSA PKCS#1 v1.5 with a 3072-bit key; 865 - key derivation using HKDF with SHA-384; and 866 - key wrap using AES-256-KEYWRAP. 868 In real-world use, the originator would encrypt the key-derivation 869 key in their own RSA public key as well as the recipient's public 870 key. This is omitted in an attempt to simplify the example. 872 A.1. Originator Processing Example 874 The pre-shared key known to Alice and Bob, in hexadecimal: 876 c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 878 The identifier assigned to the pre-shared key is: 879 ptf-kmc:13614122112 881 Alice obtains Bob's public key: 882 -----BEGIN PUBLIC KEY----- 883 MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ 884 AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH 885 Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq 886 vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx 887 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v 888 SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a 889 uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy 890 FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS 891 whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= 892 -----END PUBLIC KEY----- 894 Bob's RSA public key has the following key identifier: 895 9eeb67c9b95a74d44d2f16396680e801b5cba49c 897 Alice randomly generates a content-encryption key: 898 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 900 Alice randomly generates a key-derivation key: 901 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 903 Alice encrypts the key-derivation key in Bob's public key: 904 4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d 905 8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01 906 48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626 907 74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7 908 667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80 909 6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3 910 b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a 911 2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a 912 59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710 913 1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85 914 d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077 915 63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53 917 Alice produces a 256-bit key-encryption key with HKDF using SHA-384; 918 the secret value is the key-derivation key; the 'info' is the DER- 919 encoded CMSORIforPSKOtherInfo structure with the following values: 920 0 56: SEQUENCE { 921 2 32: OCTET STRING 922 : C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB 923 : 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15 924 36 1: ENUMERATED 5 925 39 11: SEQUENCE { 926 41 9: OBJECT IDENTIFIER aes256-wrap 927 : { 2 16 840 1 101 3 4 1 45 } 928 : } 929 52 1: INTEGER 32 930 55 1: INTEGER 32 931 : } 933 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 934 30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336 935 5cf95b150a0105300b060960864801650304012d020120020120 937 The HKDF output is 256 bits: 938 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 940 Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption 941 key with the key-encryption key: 942 ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 943 c83d0dd5d1b4faa5 945 Alice encrypts the content using AES-256-GCM with the content- 946 encryption key. The 12-octet nonce used is: 947 cafebabefacedbaddecaf888 949 The content plaintext is: 950 48656c6c6f2c20776f726c6421 952 The resulting ciphertext is: 953 9af2d16f21547fcefed9b3ef2d 955 The resulting 12-octet authentication tag is: 956 a0e5925cc184e0172463c44c 958 A.2. ContentInfo and AuthEnvelopedData 960 Alice encodes the AuthEnvelopedData and the ContentInfo, and 961 sends the result to Bob. The resulting structure is: 963 0 650: SEQUENCE { 964 4 11: OBJECT IDENTIFIER authEnvelopedData 965 : { 1 2 840 113549 1 9 16 1 23 } 966 17 633: [0] { 967 21 629: SEQUENCE { 968 25 1: INTEGER 0 969 28 551: SET { 970 32 547: [4] { 971 36 11: OBJECT IDENTIFIER ** Placeholder ** 972 : { 1 2 840 113549 1 9 16 TBD 1 } 973 49 530: SEQUENCE { 974 53 1: INTEGER 0 975 56 19: OCTET STRING 'ptf-kmc:13614122112' 976 77 13: SEQUENCE { 977 79 11: OBJECT IDENTIFIER ** Placeholder ** 978 : { 1 2 840 113549 1 9 16 3 TBD } 979 : } 980 92 11: SEQUENCE { 981 94 9: OBJECT IDENTIFIER aes256-wrap 982 : { 2 16 840 1 101 3 4 1 45 } 983 : } 984 105 432: SEQUENCE { 985 109 428: SEQUENCE { 986 113 1: INTEGER 2 987 116 20: [0] 988 : 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01 989 : B5 CB A4 9C 990 138 13: SEQUENCE { 991 140 9: OBJECT IDENTIFIER rsaEncryption 992 : { 1 2 840 113549 1 1 1 } 993 151 0: NULL 994 : } 995 153 384: OCTET STRING 996 : 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A 997 : 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5 998 : 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3 999 : A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B 1000 : 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C 1001 : 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B 1002 : FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B 1003 : 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92 1004 : 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77 1005 : FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E 1006 : 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 1007 : 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2 1008 : AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20 1009 : 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7 1010 : EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76 1011 : 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA 1012 : 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28 1013 : 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66 1014 : 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC 1015 : 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F 1016 : 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A 1017 : 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 1018 : 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C 1019 : B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF 5B 5D 1020 : } 1021 : } 1022 541 40: OCTET STRING 1023 : AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7 1024 : 15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66 1025 : C8 3D 0D D5 D1 B4 FA A5 1026 : } 1027 : } 1028 : } 1029 583 55: SEQUENCE { 1030 585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 1031 596 27: SEQUENCE { 1032 598 9: OBJECT IDENTIFIER aes256-GCM 1033 : { 2 16 840 1 101 3 4 1 46 } 1034 609 14: SEQUENCE { 1035 611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88 1036 : } 1037 : } 1038 625 13: [0] 9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D 1039 : } 1040 640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C 1041 : } 1042 : } 1043 : } 1045 A.3. Recipient Processing Example 1047 Bob's private key: 1048 -----BEGIN RSA PRIVATE KEY----- 1049 MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx 1050 WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su 1051 sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro 1052 ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q 1053 khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b 1054 JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW 1055 MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn 1056 XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd 1057 ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x 1058 jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV 1059 3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh 1060 9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs 1061 Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK 1062 q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX 1063 UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk 1064 HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7 1065 8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq 1066 haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J 1067 fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu 1068 oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh 1069 /QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q 1070 DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1 1071 0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96 1072 W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy 1073 mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4 1074 mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I 1075 SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ 1076 B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 1077 gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr 1078 ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI 1079 x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T 1080 UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ 1081 SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz 1082 AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x 1083 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 1084 sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f 1085 hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== 1086 -----END RSA PRIVATE KEY----- 1088 Bob decrypts the key-derivation key with his RSA private key: 1089 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 1091 Bob produces a 256-bit key-encryption key with HKDF using SHA-384; 1092 the secret value is the key-derivation key; the 'info' is the DER- 1093 encoded CMSORIforPSKOtherInfo structure with the same values as 1094 shown in A.1. The HKDF output is 256 bits: 1095 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 1097 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1098 with the key-encryption key; the content-encryption key is: 1099 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 1101 Bob decrypts the content using AES-256-GCM with the content- 1102 encryption key, and checks the received authentication tag. The 1103 12-octet nonce used is: 1104 cafebabefacedbaddecaf888 1106 The 12-octet authentication tag is: 1107 a0e5925cc184e0172463c44c 1109 The received ciphertext content is: 1110 9af2d16f21547fcefed9b3ef2d 1112 The resulting plaintext content is: 1113 48656c6c6f2c20776f726c6421 1115 Appendix B: Key Agreement with PSK Example 1117 This example shows the establishment of an AES-256 content-encryption 1118 key using: 1119 - a pre-shared key of 256 bits; 1120 - key agreement using ECDH on curve P-384 and X9.63 KDF 1121 with SHA-384; 1122 - key derivation using HKDF with SHA-384; and 1123 - key wrap using AES-256-KEYWRAP. 1125 In real-world use, the originator would treat themselves as an 1126 additional recipient by performing key agreement with their own 1127 static public key and the ephemeral private key generated for this 1128 message. This is omitted in an attempt to simplify the example. 1130 B.1. Originator Processing Example 1132 The pre-shared key known to Alice and Bob, in hexadecimal: 1134 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 1136 The identifier assigned to the pre-shared key is: 1137 ptf-kmc:216840110121 1139 Alice randomly generates a content-encryption key: 1140 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1142 Alice obtains Bob's static ECDH public key: 1143 -----BEGIN PUBLIC KEY----- 1144 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY 1145 /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM 1146 YkcpxMGo32z3JetEloW5aFOja13vv/W5 1147 -----END PUBLIC KEY----- 1149 It has a key identifier of: 1150 e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 1152 Alice generates an ephemeral ECDH key pair on the same curve: 1153 -----BEGIN EC PRIVATE KEY----- 1154 MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp 1155 /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA 1156 LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb 1157 GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8= 1158 -----END EC PRIVATE KEY----- 1160 Alice computes a shared secret, called Z, using the Bob's static 1161 ECDH public key and her ephemeral ECDH private key; Z is: 1162 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1163 19cf8807e6d800c2de40240fe0e26adc 1165 Alice computes the pairwise key-encryption key, called KEK1, from Z 1166 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1167 following values: 1168 0 21: SEQUENCE { 1169 2 11: SEQUENCE { 1170 4 9: OBJECT IDENTIFIER aes256-wrap 1171 : { 2 16 840 1 101 3 4 1 45 } 1172 : } 1173 15 6: [2] { 1174 17 4: OCTET STRING 00 00 00 20 1175 : } 1176 : } 1178 The DER encoding of ECC-CMS-SharedInfo produces 23 octets: 1179 3015300b060960864801650304012da206040400000020 1181 The X9.63 KDF output is the 256-bit KEK1: 1182 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1184 Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1185 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1186 structure with the following values: 1187 0 56: SEQUENCE { 1188 2 32: OCTET STRING 1189 : 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F 1190 : A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4 1191 36 1: ENUMERATED 10 1192 39 11: SEQUENCE { 1193 41 9: OBJECT IDENTIFIER aes256-wrap 1194 : { 2 16 840 1 101 3 4 1 45 } 1195 : } 1196 52 1: INTEGER 32 1197 55 1: INTEGER 32 1198 : } 1200 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 1201 303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021 1202 4e2d83e40a010a300b060960864801650304012d020120020120 1204 The HKDF output is the 256-bit KEK2: 1205 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1207 Alice uses AES-KEY-WRAP to encrypt the content-encryption key 1208 with the KEK2; the wrapped key is: 1209 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b 1210 de08866a602d63f4 1212 Alice encrypts the content using AES-256-GCM with the content- 1213 encryption key. The 12-octet nonce used is: 1214 dbaddecaf888cafebabeface 1216 The plaintext is: 1217 48656c6c6f2c20776f726c6421 1219 The resulting ciphertext is: 1220 fc6d6f823e3ed2d209d0c6ffcf 1222 The resulting 12-octet authentication tag is: 1223 550260c42e5b29719426c1ff 1225 B.2. ContentInfo and AuthEnvelopedData 1227 Alice encodes the AuthEnvelopedData and the ContentInfo, and 1228 sends the result to Bob. The resulting structure is: 1230 0 327: SEQUENCE { 1231 4 11: OBJECT IDENTIFIER authEnvelopedData 1232 : { 1 2 840 113549 1 9 16 1 23 } 1233 17 310: [0] { 1234 21 306: SEQUENCE { 1235 25 1: INTEGER 0 1236 28 229: SET { 1237 31 226: [4] { 1238 34 11: OBJECT IDENTIFIER ** Placeholder ** 1239 : { 1 2 840 113549 1 9 16 TBD 2 } 1240 47 210: SEQUENCE { 1241 50 1: INTEGER 0 1242 53 20: OCTET STRING 'ptf-kmc:216840110121' 1243 75 85: [0] { 1244 77 83: [1] { 1245 79 19: SEQUENCE { 1246 81 6: OBJECT IDENTIFIER 1247 : dhSinglePass-stdDH-sha256kdf-scheme 1248 : { 1 3 132 1 11 1 } 1249 89 9: OBJECT IDENTIFIER aes256-wrap 1250 : { 2 16 840 1 101 3 4 1 45 } 1251 : } 1252 100 60: BIT STRING, encapsulates { 1253 103 57: OCTET STRING 1254 : 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD 1255 : 4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA 1256 : FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30 1257 : E0 D2 9C B6 89 0A 36 0A 6C 1258 : } 1259 : } 1260 : } 1261 162 13: SEQUENCE { 1262 164 11: OBJECT IDENTIFIER ** Placeholder ** 1263 : { 1 2 840 113549 1 9 16 3 TBD } 1264 : } 1265 177 11: SEQUENCE { 1266 179 9: OBJECT IDENTIFIER aes256-wrap 1267 : { 2 16 840 1 101 3 4 1 45 } 1268 : } 1269 190 68: SEQUENCE { 1270 192 66: SEQUENCE { 1271 194 22: [0] { 1272 196 20: OCTET STRING 1273 : E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC 1274 : DC 05 C5 29 1275 : } 1276 218 40: OCTET STRING 1277 : 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB 1278 : 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B 1279 : DE 08 86 6A 60 2D 63 F4 1280 : } 1281 : } 1282 : } 1283 : } 1284 : } 1285 260 55: SEQUENCE { 1286 262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 1287 273 27: SEQUENCE { 1288 275 9: OBJECT IDENTIFIER aes256-GCM 1289 : { 2 16 840 1 101 3 4 1 46 } 1290 286 14: SEQUENCE { 1291 288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE 1292 : } 1293 : } 1294 302 13: [0] FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF 1295 : } 1296 317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF 1297 : } 1298 : } 1299 : } 1301 B.3. Recipient Processing Example 1303 Bob obtains Alice's ephemeral ECDH public key from the message: 1304 -----BEGIN PUBLIC KEY----- 1305 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV 1306 wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT 1307 2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v 1308 -----END PUBLIC KEY----- 1310 Bob's static ECDH private key: 1311 -----BEGIN EC PRIVATE KEY----- 1312 MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk 1313 NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9 1314 149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi 1315 RynEwajfbPcl60SWhbloU6NrXe+/9bk= 1316 -----END EC PRIVATE KEY----- 1318 Bob computes a shared secret, called Z, using the Alice's ephemeral 1319 ECDH public key and his static ECDH private key; Z is: 1320 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1321 19cf8807e6d800c2de40240fe0e26adc 1323 Bob computes the pairwise key-encryption key, called KEK1, from Z 1324 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1325 values shown in B.1. The X9.63 KDF output is the 256-bit KEK1: 1326 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1328 Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1329 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1330 structure with the values shown in B.1. The HKDF output is the 1331 256-bit KEK2: 1332 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1334 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1335 with the KEK2; the content-encryption key is: 1336 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1338 Bob decrypts the content using AES-256-GCM with the content- 1339 encryption key, and checks the received authentication tag. The 1340 12-octet nonce used is: 1341 dbaddecaf888cafebabeface 1343 The 12-octet authentication tag is: 1344 550260c42e5b29719426c1ff 1346 The received ciphertext content is: 1347 fc6d6f823e3ed2d209d0c6ffcf 1349 The resulting plaintext content is: 1350 48656c6c6f2c20776f726c6421 1352 Acknowledgements 1354 Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos 1355 Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van 1356 Geest for their review and insightful comments. They have greatly 1357 improved the design, clarity, and implementation guidance. 1359 Author's Address 1361 Russ Housley 1362 Vigil Security, LLC 1363 516 Dranesville Road 1364 Herndon, VA 20170 1365 USA 1366 EMail: housley@vigilsec.com