idnits 2.17.1 draft-ietf-lamps-cms-mix-with-psk-03.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 March 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5803' is mentioned on line 94, but not defined -- Looks like a reference, but probably isn't: '0' on line 1192 -- Looks like a reference, but probably isn't: '1' on line 1142 -- Looks like a reference, but probably isn't: '4' on line 1135 -- Looks like a reference, but probably isn't: '2' on line 1074 == Unused Reference: 'RFC3560' is defined on line 729, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-03 Summary: 1 error (**), 0 flaws (~~), 4 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: 8 September 2019 8 March 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) 2018 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 . . . . . . . . . . . . . . . . . . . . 14 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 72 10.2. Informative References . . . . . . . . . . . . . . . . . 16 73 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17 74 A.1. Originator Processing Example . . . . . . . . . . . . . . 17 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. It is an open question whether or not it is feasible to build 89 a large-scale quantum computer, and if so, when that might happen. 90 However, if such a quantum computer is invented, many of the 91 cryptographic algorithms and the security protocols that use them 92 would become vulnerable. 94 The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] 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 invulnerable 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-Hellamn parameters. Inclusion of a strong PSK as 128 part of the overall key management offer additional protection 129 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. KeyTransPSKRecipientInfo 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. KeyAgreePSKRecipientInfo 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 make use fo 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 deines 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 CMSORIforPSK-2019 465 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 466 smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) } 468 DEFINITIONS EXPLICIT TAGS ::= 469 BEGIN 471 -- EXPORTS All 473 IMPORTS 475 AlgorithmIdentifier{}, KEY-DERIVATION 476 FROM AlgorithmInformation-2009 -- [RFC5912] 477 { iso(1) identified-organization(3) dod(6) internet(1) 478 security(5) mechanisms(5) pkix(7) id-mod(0) 479 id-mod-algorithmInformation-02(58) } 481 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 482 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 483 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 484 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 485 FROM CryptographicMessageSyntax-2009 -- [RFC5911] 486 { iso(1) member-body(2) us(840) rsadsi(113549) 487 pkcs(1) pkcs-9(9) smime(16) modules(0) 488 id-mod-cms-2004-02(41) } ; 490 -- 491 -- OtherRecipientInfo Types (ori-) 492 -- 494 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 495 ori-keyTransPSK | 496 ori-keyAgreePSK, 497 ... } 499 -- 500 -- Key Transport with Pre-Shared Key 501 -- 503 ori-keyTransPSK OTHER-RECIPIENT ::= { 504 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 506 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 507 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 509 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 510 KeyTransPSKRecipientInfo ::= SEQUENCE { 511 version CMSVersion, -- always set to 0 512 pskid PreSharedKeyIdentifier, 513 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 514 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 515 ktris KeyTransRecipientInfos, 516 encryptedKey EncryptedKey } 518 PreSharedKeyIdentifier ::= OCTET STRING 520 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 522 -- 523 -- Key Agreement with Pre-Shared Key 524 -- 526 ori-keyAgreePSK ORI-TYPE ::= { 527 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 529 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 531 KeyAgreePSKRecipientInfo ::= SEQUENCE { 532 version CMSVersion, -- always set to 0 533 pskid PreSharedKeyIdentifier, 534 originator [0] EXPLICIT OriginatorIdentifierOrKey, 535 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 536 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 537 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 538 recipientEncryptedKeys RecipientEncryptedKeys } 540 -- 541 -- Structure to provide 'info' input to the KDF, 542 -- including the Pre-Shared Key 543 -- 545 CMSORIforPSKOtherInfo ::= SEQUENCE { 546 psk OCTET STRING, 547 keyMgmtAlgType ENUMERATED { 548 keyTrans (5), 549 keyAgree (10) }, 550 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 551 pskLength INTEGER (1..MAX), 552 kdkLength INTEGER (1..MAX) } 554 END 556 7. Security Considerations 558 Implementations must protect the pre-shared key (PSK), key transport 559 private key, the agreement private key, the key-derivation key, and 560 the key-encryption key. Compromise of the PSK will make the 561 encrypted content vulnerable to the future invention of a large-scale 562 quantum computer. Compromise of the PSK and either the key transport 563 private key or the agreement private key may result in the disclosure 564 of all contents protected with that combination of keying material. 565 Compromise of the PSK and the key-derivation key may result in 566 disclosure of all contents protected with that combination of keying 567 material. Compromise of the key-encryption key may result in the 568 disclosure of all content-encryption keys or content-authenticated- 569 encryption keys that were protected with that keying materail, which 570 in turn may result in the disclosure of the content. 572 A large-scale quantum computer will essentially negate the security 573 provided by the key transport algorithm or the key agreement 574 algorithm, which means that the attacker with a large-scale quantum 575 computer can discover the key-derivation key. In addition a large- 576 scale quantum computer effectively cuts the security provided by a 577 symmetric key algorithm in half. Therefore, the PSK needs at least 578 256 bits of entropy to provide 128 bits of security. To match that 579 same level of security, the key derivation function needs to be 580 quantum-resistant and produce a key-encryption key that is at least 581 256 bits in length. Similarly, the content-encryption key or 582 content-authenticated-encryption key needs to be at least 256 bits in 583 length. 585 When using a PSK with a key transport or a key agreement algorithm, a 586 key-encryption key is produced to encrypt the content-encryption key 587 or content-authenticated-encryption key. If the key-encryption 588 algorithm is different than the algorithm used to protect the 589 content, then the effective security is determined by the weaker of 590 the two algorithms. If, for example, content is encrypted with 591 256-bit AES, and the key is wrapped with 128-bit AES, then at most 592 128 bits of protection is provided. Implementers must ensure that 593 the key-encryption algorithm is as strong or stronger than the 594 content-encryption algorithm or content-authenticated-encryption 595 algorithm. 597 Implementers should not mix quantum-resistant key management 598 algorithms with their non-quantum-resistant counterparts. For 599 example, the same content should not be protected with 600 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 601 same content should not be protected with KeyAgreeRecipientInfo and 602 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 603 to the future invention of a large-scale quantum computer. 605 Implementers should not send the same content in different messages, 606 one using a quantum-resistant key management algorithm and the other 607 using a non-quantum-resistant key management algorithm, even if the 608 content-encryption key is generated independently. Doing so may 609 allow an eavesdropper to correlate the messages, making the content 610 vulnerable to the future invention of a large-scale quantum computer. 612 Sound cryptographic key hygiene is to use a key for one and only one 613 purpose. Use of the recipient's public key for both the traditional 614 CMS and the PSK-mixing variation specified in this document would be 615 a violations of this principle; however, there is no known way for an 616 attacker to take advantage of this situation. However, an 617 application should enforce separation whenever possible. For 618 example, an purpose identifier for use in the X.509 extended key 619 usage certificate extension [RFC5280] could be identified in the 620 future to indicate that a public key should only be used in 621 conjunction with a PSK, or only without. 623 Implementations must randomly generate key-derivation keys as well as 624 the content-encryption keys or content-authenticated-encryption keys. 625 Also, the generation of public/private key pairs for the key 626 transport and key agreement algorithms rely on a random numbers. The 627 use of inadequate pseudo-random number generators (PRNGs) to generate 628 cryptographic keys can result in little or no security. An attacker 629 may find it much easier to reproduce the PRNG environment that 630 produced the keys, searching the resulting small set of 631 possibilities, rather than brute force searching the whole key space. 632 The generation of quality random numbers is difficult. [RFC4086] 633 offers important guidance in this area. 635 Implementers should be aware that cryptographic algorithms become 636 weaker with time. As new cryptoanalysis techniques are developed and 637 computing performance improves, the work factor to break a particular 638 cryptographic algorithm will be reduced. Therefore, cryptographic 639 algorithm implementations should be modular, allowing new algorithms 640 to be readily inserted. That is, implementors should be prepared for 641 the set of supported algorithms to change over time. 643 8. Privacy Considerations 645 An observer can see which parties are using each PSK simply by 646 watching the PSK key identifiers. However, the addition of these key 647 identifiers is not really making privacy worse. When key transport 648 is used, the RecipientIdentifier is always present, and it clearly 649 identifies each recipient to an observer. When key agreement is 650 used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier 651 is always present, and these clearly identify each recipient. 653 9. IANA Considerations 655 One object identifier for the ASN.1 module in the Section 5 was 656 assigned in the SMI Security for S/MIME Module Identifiers 657 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 659 id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { 660 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 661 pkcs-9(9) smime(16) mod(0) TBD0 } 663 One object identifier for an arc to assign Other Recipient Info 664 Identifiers was assigned in the SMI Security for S/MIME Mail Security 665 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 667 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 668 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 670 This assignment created the new SMI Security for Other Recipient Info 671 Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the 672 following two entries with references to this document: 674 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 675 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 676 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 678 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 679 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 680 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 682 10. References 684 10.1. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 690 Authenticated-Enveloped-Data Content Type", RFC 5083, 691 November 2007. 693 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 694 5652, September 2009. 696 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 697 2119 Key Words", BCP 14, RFC 8174, May 2017. 699 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 700 One (ASN.1): Specification of basic notation", ITU-T 701 Recommendation X.680, 2015. 703 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 704 Specification of Basic Encoding Rules (BER), Canonical 705 Encoding Rules (CER) and Distinguished Encoding Rules 706 (DER)", ITU-T Recommendation X.690, 2015. 708 10.2. Informative References 710 [AES] National Institute of Standards and Technology, FIPS Pub 711 197: Advanced Encryption Standard (AES), 26 November 2001. 713 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 714 Quantum Cryptography", work-in-progress, draft-hoffman- 715 c2pq-03, February 2018. 717 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 718 numbers.xhtml#security-smime-0. 720 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 721 numbers.xhtml#security-smime. 723 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 724 numbers.xhtml#security-smime-13. 726 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 727 RFC 2631, June 1999. 729 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 730 Algorithm in Cryptographic Message Syntax (CMS)", 731 RFC 3560, July 2003. 733 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 734 "Randomness Requirements for Security", RFC 4086, 735 June 2005. 737 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 738 Housley, R., and W. Polk, "Internet X.509 Public Key 739 Infrastructure Certificate and Certificate Revocation List 740 (CRL) Profile", RFC 5280, May 2008. 742 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 743 Cryptography (ECC) Algorithms in Cryptographic Message 744 Syntax (CMS)", RFC 5753, January 2010. 746 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 747 Expand Key Derivation Function (HKDF)", RFC 5869, 748 May 2010. 750 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 751 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 752 June 2010. 754 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 755 Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, 756 June 2010. 758 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 759 "PKCS #1: RSA Cryptography Specifications Version 2.2", 760 RFC 8017, November 2016. 762 Appendix A: Key Transport with PSK Example 764 This example shows the establishment of an AES-256 content-encryption 765 key using: 766 - a pre-shared key of 256 bits; 767 - key transport using RSA PKCS#1 v1.5 with a 3072-bit key; 768 - key derivation using HKDF with SHA-384; and 769 - key wrap using AES-256-KEYWRAP. 771 In real-world use, the originator would encrypt the key-derivation 772 key in their own RSA public key as well as the recipient's public 773 key. This is omited in an attempt to simplify the example. 775 A.1. Originator Processing Example 777 The pre-shared key known to Alice and Bob: 778 c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 780 The identifier assigned to the pre-shared key is: 781 ptf-kmc:13614122112 783 Alice obtains Bob's public key: 784 -----BEGIN PUBLIC KEY----- 785 MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ 786 AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH 787 Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq 788 vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx 789 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v 790 SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a 791 uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy 792 FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS 793 whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= 794 -----END PUBLIC KEY----- 796 Bob's RSA public key has the following key identifier: 797 9eeb67c9b95a74d44d2f16396680e801b5cba49c 799 Alice randomly generates a content-encryption key: 800 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 802 Alice randomly generates a key-derivation key: 803 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 805 Alice encrypts the key-derivation key in Bob's public key: 806 4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d 807 8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01 808 48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626 809 74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7 810 667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80 811 6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3 812 b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a 813 2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a 814 59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710 815 1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85 816 d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077 817 63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53 819 Alice produces a 256-bit key-encryption key with HKDF using SHA-384; 820 the secret value is the key-derivation key; the 'info' is the DER- 821 encoded CMSORIforPSKOtherInfo structure with the following values: 822 0 56: SEQUENCE { 823 2 32: OCTET STRING 824 : C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB 825 : 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15 826 36 1: ENUMERATED 5 827 39 11: SEQUENCE { 828 41 9: OBJECT IDENTIFIER aes256-wrap 829 : { 2 16 840 1 101 3 4 1 45 } 830 : } 831 52 1: INTEGER 32 832 55 1: INTEGER 32 833 : } 835 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 836 30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336 837 5cf95b150a0105300b060960864801650304012d020120020120 839 The HKDF output is 256 bits: 840 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 842 Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption 843 key with the key-encryption key: 844 ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 845 c83d0dd5d1b4faa5 847 Alice encrypts the content using AES-256-GCM with the content- 848 encryption key. The 12-octet nonce used is: 849 cafebabefacedbaddecaf888 851 The content plaintext is: 852 48656c6c6f2c20776f726c6421 854 The resutling ciphertext is: 855 9af2d16f21547fcefed9b3ef2d 857 The resutling 12-octet authentication tag is: 858 a0e5925cc184e0172463c44c 860 A.2. ContentInfo and AuthEnvelopedData 862 Alice encodes the AuthEnvelopedData and the ContentInfo, and 863 sends the result to Bob. The resulting structure is: 865 0 650: SEQUENCE { 866 4 11: OBJECT IDENTIFIER authEnvelopedData 867 : { 1 2 840 113549 1 9 16 1 23 } 868 17 633: [0] { 869 21 629: SEQUENCE { 870 25 1: INTEGER 0 871 28 551: SET { 872 32 547: [4] { 873 36 11: OBJECT IDENTIFIER ** Placeholder ** 874 : { 1 2 840 113549 1 9 16 TBD 1 } 875 49 530: SEQUENCE { 876 53 1: INTEGER 0 877 56 19: OCTET STRING 'ptf-kmc:13614122112' 878 77 13: SEQUENCE { 879 79 11: OBJECT IDENTIFIER ** Placeholder ** 880 : { 1 2 840 113549 1 9 16 3 TBD } 881 : } 882 92 11: SEQUENCE { 883 94 9: OBJECT IDENTIFIER aes256-wrap 884 : { 2 16 840 1 101 3 4 1 45 } 885 : } 886 105 432: SEQUENCE { 887 109 428: SEQUENCE { 888 113 1: INTEGER 2 889 116 20: [0] 890 : 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01 891 : B5 CB A4 9C 892 138 13: SEQUENCE { 893 140 9: OBJECT IDENTIFIER rsaEncryption 894 : { 1 2 840 113549 1 1 1 } 895 151 0: NULL 896 : } 897 153 384: OCTET STRING 898 : 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A 899 : 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5 900 : 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3 901 : A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B 902 : 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C 903 : 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B 904 : FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B 905 : 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92 906 : 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77 907 : FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E 908 : 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 909 : 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2 910 : AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20 911 : 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7 912 : EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76 913 : 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA 914 : 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28 915 : 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66 916 : 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC 917 : 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F 918 : 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A 919 : 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 920 : 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C 921 : B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF 5B 5D 922 : } 923 : } 924 541 40: OCTET STRING 925 : AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7 926 : 15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66 927 : C8 3D 0D D5 D1 B4 FA A5 928 : } 929 : } 930 : } 931 583 55: SEQUENCE { 932 585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 933 596 27: SEQUENCE { 934 598 9: OBJECT IDENTIFIER aes256-GCM 935 : { 2 16 840 1 101 3 4 1 46 } 936 609 14: SEQUENCE { 937 611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88 938 : } 939 : } 940 625 13: [0] 9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D 941 : } 942 640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C 943 : } 944 : } 945 : } 947 A.3. Recipient Processing Example 949 Bob's private key: 950 -----BEGIN RSA PRIVATE KEY----- 951 MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx 952 WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su 953 sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro 954 ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q 955 khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b 956 JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW 957 MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn 958 XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd 959 ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x 960 jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV 961 3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh 962 9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs 963 Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK 964 q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX 965 UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk 966 HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7 967 8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq 968 haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J 969 fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu 970 oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh 971 /QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q 972 DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1 973 0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96 974 W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy 975 mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4 976 mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I 977 SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ 978 B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 979 gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr 980 ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI 981 x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T 982 UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ 983 SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz 984 AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x 985 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 986 sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f 987 hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== 988 -----END RSA PRIVATE KEY----- 990 Bob decrypts the key-derivation key with his RSA private key: 991 df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 993 Bob produces a 256-bit key-encryption key with HKDF using SHA-384; 994 the secret value is the key-derivation key; the 'info' is the DER- 995 encoded CMSORIforPSKOtherInfo structure with the same values as 996 shown in A.1. The HKDF output is 256 bits: 997 a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 999 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1000 with the key-encryption key; the content-encryption key is: 1001 c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 1003 Bob decrypts the content using AES-256-GCM with the content- 1004 encryption key, and checks the received authentication tag. The 1005 12-octet nonce used is: 1006 cafebabefacedbaddecaf888 1008 The 12-octet authentication tag is: 1009 a0e5925cc184e0172463c44c 1011 The received ciphertext content is: 1012 9af2d16f21547fcefed9b3ef2d 1014 The resutling plaintext content is: 1015 48656c6c6f2c20776f726c6421 1017 Appendix B: Key Agreement with PSK Example 1019 This example shows the establishment of an AES-256 content-encryption 1020 key using: 1021 - a pre-shared key of 256 bits; 1022 - key agreement using ECDH on curve P-384 and X9.63 KDF 1023 with SHA-384; 1024 - key derivation using HKDF with SHA-384; and 1025 - key wrap using AES-256-KEYWRAP. 1027 In real-world use, the originator would treat themselves as an additional 1028 recipient by performing key agreement with their own static public key 1029 the ephemeral private key generated for this message. This is omited in 1030 an attempt to simplify the example. 1032 B.1. Originator Processing Example 1034 The pre-shared key known to Alice and Bob: 1035 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 1037 The identifier assigned to the pre-shared key is: 1038 ptf-kmc:216840110121 1040 Alice randomly generates a content-encryption key: 1041 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1043 Alice obtains Bob's static ECDH public key: 1044 -----BEGIN PUBLIC KEY----- 1045 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY 1046 /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM 1047 YkcpxMGo32z3JetEloW5aFOja13vv/W5 1048 -----END PUBLIC KEY----- 1050 It has a key identifier of: 1051 e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 1053 Alice generates an ephemeral ECDH key pair on the same curve: 1054 -----BEGIN EC PRIVATE KEY----- 1055 MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp 1056 /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA 1057 LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb 1058 GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8= 1059 -----END EC PRIVATE KEY----- 1061 Alice computes a shared secret, called Z, using the Bob's static 1062 ECDH public key and her ephemeral ECDH private key; Z is: 1063 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1064 19cf8807e6d800c2de40240fe0e26adc 1066 Alice computes the pairwise key-encryption key, called KEK1, from Z 1067 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1068 following values: 1069 0 21: SEQUENCE { 1070 2 11: SEQUENCE { 1071 4 9: OBJECT IDENTIFIER aes256-wrap 1072 : { 2 16 840 1 101 3 4 1 45 } 1073 : } 1074 15 6: [2] { 1075 17 4: OCTET STRING 00 00 00 20 1076 : } 1077 : } 1079 The DER encoding of ECC-CMS-SharedInfo produces 23 octets: 1080 3015300b060960864801650304012da206040400000020 1082 The X9.63 KDF output is the 256-bit KEK1: 1083 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1085 Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1086 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1087 structure with the following values: 1088 0 56: SEQUENCE { 1089 2 32: OCTET STRING 1090 : 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F 1091 : A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4 1092 36 1: ENUMERATED 10 1093 39 11: SEQUENCE { 1094 41 9: OBJECT IDENTIFIER aes256-wrap 1095 : { 2 16 840 1 101 3 4 1 45 } 1096 : } 1097 52 1: INTEGER 32 1098 55 1: INTEGER 32 1099 : } 1101 The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 1102 303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021 1103 4e2d83e40a010a300b060960864801650304012d020120020120 1105 The HKDF output is the 256-bit KEK2: 1106 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1108 Alice uses AES-KEY-WRAP to encrypt the content-encryption key 1109 with the KEK2; the wrapped key is: 1110 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b 1111 de08866a602d63f4 1113 Alice encrypts the content using AES-256-GCM with the content- 1114 encryption key. The 12-octet nonce used is: 1115 dbaddecaf888cafebabeface 1117 The resulting ciphertext is: 1118 fc6d6f823e3ed2d209d0c6ffcf 1120 The resulting 12-octet authentication tag is: 1121 550260c42e5b29719426c1ff 1123 B.2. ContentInfo and AuthEnvelopedData 1125 Alice encodes the AuthEnvelopedData and the ContentInfo, and 1126 sends the result to Bob. The resulting structure is: 1128 0 327: SEQUENCE { 1129 4 11: OBJECT IDENTIFIER authEnvelopedData 1130 : { 1 2 840 113549 1 9 16 1 23 } 1131 17 310: [0] { 1132 21 306: SEQUENCE { 1133 25 1: INTEGER 0 1134 28 229: SET { 1135 31 226: [4] { 1136 34 11: OBJECT IDENTIFIER ** Placeholder ** 1137 : { 1 2 840 113549 1 9 16 TBD 2 } 1138 47 210: SEQUENCE { 1139 50 1: INTEGER 0 1140 53 20: OCTET STRING 'ptf-kmc:216840110121' 1141 75 85: [0] { 1142 77 83: [1] { 1143 79 19: SEQUENCE { 1144 81 6: OBJECT IDENTIFIER 1145 : dhSinglePass-stdDH-sha256kdf-scheme 1146 : { 1 3 132 1 11 1 } 1147 89 9: OBJECT IDENTIFIER aes256-wrap 1148 : { 2 16 840 1 101 3 4 1 45 } 1149 : } 1150 100 60: BIT STRING, encapsulates { 1151 103 57: OCTET STRING 1152 : 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD 1153 : 4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA 1154 : FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30 1155 : E0 D2 9C B6 89 0A 36 0A 6C 1156 : } 1157 : } 1158 : } 1159 162 13: SEQUENCE { 1160 164 11: OBJECT IDENTIFIER ** Placeholder ** 1161 : { 1 2 840 113549 1 9 16 3 TBD } 1162 : } 1163 177 11: SEQUENCE { 1164 179 9: OBJECT IDENTIFIER aes256-wrap 1165 : { 2 16 840 1 101 3 4 1 45 } 1166 : } 1167 190 68: SEQUENCE { 1168 192 66: SEQUENCE { 1169 194 22: [0] { 1170 196 20: OCTET STRING 1171 : E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC 1172 : DC 05 C5 29 1173 : } 1174 218 40: OCTET STRING 1175 : 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB 1176 : 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B 1177 : DE 08 86 6A 60 2D 63 F4 1178 : } 1179 : } 1180 : } 1181 : } 1182 : } 1183 260 55: SEQUENCE { 1184 262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 1185 273 27: SEQUENCE { 1186 275 9: OBJECT IDENTIFIER aes256-GCM 1187 : { 2 16 840 1 101 3 4 1 46 } 1188 286 14: SEQUENCE { 1189 288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE 1190 : } 1191 : } 1192 302 13: [0] FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF 1193 : } 1194 317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF 1195 : } 1196 : } 1197 : } 1199 B.3. Recipient Processing Example 1201 Bob obtains Alice's ephemeral ECDH public key from the message: 1202 -----BEGIN PUBLIC KEY----- 1203 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV 1204 wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT 1205 2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v 1206 -----END PUBLIC KEY----- 1208 Bob's static ECDH private key: 1209 -----BEGIN EC PRIVATE KEY----- 1210 MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk 1211 NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9 1212 149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi 1213 RynEwajfbPcl60SWhbloU6NrXe+/9bk= 1214 -----END EC PRIVATE KEY----- 1216 Bob computes a shared secret, called Z, using the Alice's ephemeral 1217 ECDH public key and his static ECDH private key; Z is: 1218 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 1219 19cf8807e6d800c2de40240fe0e26adc 1221 Bob computes the pairwise key-encryption key, called KEK1, from Z 1222 using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the 1223 values shown in B.1. The X9.63 KDF output is the 256-bit KEK1: 1224 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 1226 Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret 1227 value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo 1228 structure with the values shown in B.1. The HKDF output is the 1229 256-bit KEK2: 1230 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb 1232 Bob uses AES-KEY-WRAP to decrypt the content-encryption key 1233 with the KEK2; the content-encryption key is: 1234 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 1236 Bob decrypts the content using AES-256-GCM with the content- 1237 encryption key, and checks the received authentication tag. The 1238 12-octet nonce used is: 1239 dbaddecaf888cafebabeface 1241 The 12-octet authentication tag is: 1242 550260c42e5b29719426c1ff 1244 The received ciphertext content is: 1245 fc6d6f823e3ed2d209d0c6ffcf 1247 The resutling plaintext content is: 1248 48656c6c6f2c20776f726c6421 1250 Acknowledgements 1252 Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean 1253 Turner, and Daniel Van Geest for their review and insightful 1254 comments. They have greatly improved the design, clarity, and 1255 implementation guidance. 1257 Author's Address 1259 Russ Housley 1260 Vigil Security, LLC 1261 516 Dranesville Road 1262 Herndon, VA 20170 1263 USA 1264 EMail: housley@vigilsec.com