idnits 2.17.1 draft-housley-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 171 has weird spacing: '...ivation funct...' -- The document date (5 March 2018) is 2238 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 82, but not defined == Missing Reference: 'RFC4055' is mentioned on line 85, but not defined -- Looks like a reference, but probably isn't: '0' on line 414 -- Looks like a reference, but probably isn't: '1' on line 415 == Unused Reference: 'RFC3560' is defined on line 565, 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-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Proposed Standard Vigil Security 4 Expires: 5 September 2018 5 March 2018 6 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) 7 9 Abstract 11 The invention of a large-scale quantum computer would pose a serious 12 challenge for the cryptographic algorithms that are widely deployed 13 today. The Cryptographic Message Syntax (CMS) supports key transport 14 and key agreement algorithms that could be broken by the invention of 15 such a quantum computer. By storing communications that are 16 protected with the CMS today, someone could decrypt them in the 17 future when a large-scale quantum computer becomes available. Once 18 quantum-secure key management algorithms are available, the CMS will 19 be extended to support them, if current syntax the does not 20 accommodated them. In the near-term, this document describes a 21 mechanism to protect today's communication from the future invention 22 of a large-scale quantum computer by mixing the output of key 23 transport and key agreement algorithms with a pre-shared key. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5 63 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 64 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 68 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The invention of a large-scale quantum computer would pose a serious 75 challenge for the cryptographic algorithms that are widely deployed 76 today. It is an open question whether or not it is feasible to build 77 a large-scale quantum computer, and if so, when that might happen. 78 However, if such a quantum computer is invented, many of the 79 cryptographic algorithms and the security protocols that use them 80 would become vulnerable. 82 The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] supports 83 key transport and key agreement algorithms that could be broken by 84 the invention of a large-scale quantum computer [C2PQ]. These 85 algorithms include RSA [RFC4055], Diffie-Hellman [RFC2631], and 86 Elliptic Curve Diffie-Hellman. As a result, an adversary that stores 87 CMS-protected communications today, could decrypt those 88 communications in the future when a large-scale quantum computer 89 becomes available. 91 Once quantum-secure key management algorithms are available, the CMS 92 will be extended to support them, if current syntax the does not 93 accommodated them. 95 In the near-term, this document describes a mechanism to protect 96 today's communication from the future invention of a large-scale 97 quantum computer by mixing the output of existing key transport and 98 key agreement algorithms with a pre-shared key (PSK). Secure 99 communication can be achieved today by mixing with a strong PSK with 100 the output of an existing key transport algorithm, like RSA, or an 101 existing key agreement algorithm, like Diffie-Hellman [RFC2631] or 102 Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is 103 believed to be quantum resistant can be achieved by using a PSK with 104 sufficient entropy along with a quantum resistant key derivation 105 function (KDF), like HKDF [RFC5869], and a quantum resistant 106 encryption algorithm, like 256-bit AES [AES]. In this way, today's 107 CMS-protected communication can be invulnerable to an attacker with a 108 large-scale quantum computer. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 1.2. ASN.1 120 CMS values are generated using ASN.1 [X680], which uses the Basic 121 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 122 [X690]. 124 1.3. Version Numbers 126 The major data structures include a version number as the first item 127 in the data structure. The version number is intended to avoid ASN.1 128 decode errors. Some implementations do not check the version number 129 prior to attempting a decode, and then if a decode error occurs, the 130 version number is checked as part of the error handling routine. 131 This is a reasonable approach; it places error processing outside of 132 the fast path. This approach is also forgiving when an incorrect 133 version number is used by the sender. 135 Whenever the structure is updated, a higher version number will be 136 assigned. However, to ensure maximum interoperability, the higher 137 version number is only used when the new syntax feature is employed. 138 That is, the lowest version number that supports the generated syntax 139 is used. 141 2. Overview 143 The CMS enveloped-data content type [RFC5652] and the CMS 144 authenticated-enveloped-data content type [RFC5083] support both key 145 transport and key agreement public-key algorithms to establish the 146 key used to encrypt the content. In both cases, the sender randomly 147 generates the key, and then all recipient obtain that key. For 148 enveloped-data, a content-encryption key is established. For 149 authenticated-enveloped-data, a content-authenticated-encryption key 150 is established. All recipients use the sender-generated key for 151 decryption. 153 This specification defines two quantum-resistant ways to establish 154 these keys. In both cases, a PSK MUST be distributed to the sender 155 and all of the recipients by some out-of-band means that does not 156 make it vulnerable to the future invention of a large-scale quantum 157 computer, and an identifier MUST be assigned to the PSK. 159 The content-encryption key or content-authenticated-encryption key is 160 established by following these steps: 162 1. The content-encryption key or the content-authenticated-encryption 163 key is generated at random. 165 2. The key-derivation key is generated at random. 167 3. The key-encryption key is established for each recipient. The 168 details depend on the key management algorithm used: 170 key transport: the key-derivation key is encrypted in the 171 recipient's public key, then the key derivation function (KDF) 172 is used to mix the pre-shared key (PSK) and the key-derivation 173 key to produce the key-encryption key; or 175 key agreement: the recipient's public key and the sender's 176 private key are used to generate a pairwise symmetric key, then 177 the key derivation function (KDF) is used to mix the pre-shared 178 key (PSK) and the pairwise symmetric key to produce the key- 179 encryption key. 181 4. The key-encryption key is used to encrypt the content-encryption 182 key or content-authenticated-encryption key. 184 As specified in Section 6.2.5 of [RFC5652], recipient information for 185 additional key management techniques are represented in the 186 OtherRecipientInfo type. Two key management techniques are specified 187 in this document. Each of these is identified by a unique ASN.1 188 object identifier. 190 The first key management technique, called keyTransPSK, see Section 191 3, uses a key transport algorithm to transfer the key-derivation key 192 from the sender to the recipient, and then key-derivation key is 193 mixed with the PSK using a KDF. The output of the KDF is the key- 194 encryption key for the encryption of the content-encryption key or 195 content-authenticated-encryption key. 197 The second key management technique, called keyAgreePSK, see Section 198 4, uses a key agreement algorithm to establish a pairwise key- 199 encryption key, which is used to encrypt the key-derivation key, and 200 then key-derivation key is mixed with the PSK using a KDF. The 201 output of the KDF is the key-encryption key for the encryption of the 202 content-encryption key or content-authenticated-encryption key. 204 3. KeyTransPSKRecipientInfo 206 Per-recipient information using keyTransPSK is represented in the 207 KeyTransPSKRecipientInfo type, and its use is indicated by the id- 208 ori-keyTransPSK object identifier. Each instance of 209 KeyTransPSKRecipientInfo establishes the content-encryption key or 210 content-authenticated-encryption key for one or more recipients that 211 have access to the same PSK. 213 The id-ori-keyTransPSK object identifier is: 215 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 216 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 218 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 220 The KeyTransPSKRecipientInfo type is: 222 KeyTransPSKRecipientInfo ::= SEQUENCE { 223 version CMSVersion, -- always set to 0 224 pskid PreSharedKeyIdentifier, 225 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 226 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 227 ktris KeyTransRecipientInfos, 228 encryptedKey EncryptedKey } 230 PreSharedKeyIdentifier ::= OCTET STRING 232 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 234 The fields of the KeyTransPSKRecipientInfo type have the following 235 meanings: 237 version is the syntax version number. The version MUST be 0. The 238 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 240 pskid is the identifier of the PSK used by the sender. The 241 identifier is an OCTET STRING, and it need not be human readable. 243 kdfAlgorithm identifies the key-derivation algorithm, and any 244 associated parameters, used by the sender to mix the key- 245 derivation key and the PSK to generate the key-encryption key. 246 The KeyDerivationAlgorithmIdentifier is described in Section 247 10.1.6 of [RFC5652]. 249 keyEncryptionAlgorithm identifies a key-encryption algorithm used 250 to encrypt the content-encryption key. The 251 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 252 [RFC5652]. 254 ktris contains one KeyTransRecipientInfo type for each recipient; 255 it uses a key transport algorithm to establish the key-derivation 256 key. KeyTransRecipientInfo is described in Section 6.2.1 of 257 [RFC5652]. 259 encryptedKey is the result of encrypting the content-encryption 260 key or the content-authenticated-encryption key with the key- 261 encryption key. EncryptedKey is an OCTET STRING. 263 4. KeyAgreePSKRecipientInfo 265 Per-recipient information using keyAgreePSK is represented in the 266 KeyAgreePSKRecipientInfo type, and its use is indicated by the id- 267 ori-keyAgreePSK object identifier. Each instance of 268 KeyAgreePSKRecipientInfo establishes the content-encryption key or 269 content-authenticated-encryption key for one or more recipients that 270 have access to the same PSK. 272 The id-ori-keyAgreePSK object identifier is: 274 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 276 The KeyAgreePSKRecipientInfo type is: 278 KeyAgreePSKRecipientInfo ::= SEQUENCE { 279 version CMSVersion, -- always set to 0 280 pskid PreSharedKeyIdentifier, 281 originator [0] EXPLICIT OriginatorIdentifierOrKey, 282 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 283 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 284 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 285 recipientEncryptedKeys RecipientEncryptedKeys } 287 The fields of the KeyAgreePSKRecipientInfo type have the following 288 meanings: 290 version is the syntax version number. The version MUST be 0. The 291 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 293 pskid is the identifier of the PSK used by the sender. The 294 identifier is an OCTET STRING, and it need not be human readable. 296 originator is a CHOICE with three alternatives specifying the 297 sender's key agreement public key. Implementations MUST support 298 all three alternatives for specifying the sender's public key. 299 The sender uses the corresponding private key and the recipient's 300 public key to generate a pairwise key. A key derivation function 301 (KDF) is used to mix the PSK and the pairwise key to produce a 302 key-encryption key. The OriginatorIdentifierOrKey type is 303 described in Section 6.2.2 of [RFC5652]. 305 ukm is optional. With some key agreement algorithms, the sender 306 provides a User Keying Material (UKM) to ensure that a different 307 key is generated each time the same two parties generate a 308 pairwise key. Implementations MUST accept a 309 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 310 Implementations that do not support key agreement algorithms that 311 make use of UKMs MUST gracefully handle the presence of UKMs. The 312 UserKeyingMaterial type is described in Section 10.2.6 of 313 [RFC5652]. 315 kdfAlgorithm identifies the key-derivation algorithm, and any 316 associated parameters, used by the sender to mix the pairwise key 317 and the PSK. The KeyDerivationAlgorithmIdentifier is described in 318 Section 10.1.6 of [RFC5652]. 320 keyEncryptionAlgorithm identifies a key-encryption algorithm used 321 to encrypt the content-encryption key or the content- 322 authenticated-encryption key. The 323 KeyEncryptionAlgorithmIdentifier type is described in Section 324 10.1.3 of [RFC5652]. 326 recipientEncryptedKeys includes a recipient identifier and 327 encrypted key for one or more recipients. The 328 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 329 specifying the recipient's certificate, and thereby the 330 recipient's public key, that was used by the sender to generate a 331 pairwise key. The encryptedKey is the result of encrypting the 332 content-encryption key or the content-authenticated-encryption key 333 with the key-encryption key. EncryptedKey is an OCTET STRING. 334 The RecipientEncryptedKeys type is defined in Section 6.2.2 of 335 [RFC5652]. 337 5. ASN.1 Module 339 This section contains the ASN.1 module for the two key management 340 techniques defined in this document. This module imports types from 341 other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. 343 CMSORIforPSK-2017 344 { iso(1) member-body(2) us(840) rsadsi(113549) 345 pkcs(1) pkcs-9(9) smime(16) modules(0) 346 id-mod-cms-ori-psk-2017(TBD0) } 348 DEFINITIONS IMPLICIT TAGS ::= 349 BEGIN 351 -- EXPORTS All 353 IMPORTS 355 AlgorithmIdentifier{}, KEY-DERIVATION 356 FROM AlgorithmInformation-2009 -- [RFC5912] 357 { iso(1) identified-organization(3) dod(6) internet(1) 358 security(5) mechanisms(5) pkix(7) id-mod(0) 359 id-mod-algorithmInformation-02(58) } 361 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 362 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 363 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 364 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 365 FROM CryptographicMessageSyntax-2009 -- [RFC5911] 366 { iso(1) member-body(2) us(840) rsadsi(113549) 367 pkcs(1) pkcs-9(9) smime(16) modules(0) 368 id-mod-cms-2004-02(41) } ; 370 -- 371 -- OtherRecipientInfo Types (ori-) 372 -- 374 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 375 ori-keyTransPSK | 376 ori-keyAgreePSK, 377 ... } 379 -- 380 -- Key Transport with Pre-Shared Key 381 -- 383 ori-keyTransPSK OTHER-RECIPIENT ::= { 384 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 386 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 387 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 389 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 391 KeyTransPSKRecipientInfo ::= SEQUENCE { 392 version CMSVersion, -- always set to 0 393 pskid PreSharedKeyIdentifier, 394 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 395 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 396 ktris KeyTransRecipientInfos, 397 encryptedKey EncryptedKey } 399 PreSharedKeyIdentifier ::= OCTET STRING 401 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 403 -- 404 -- Key Agreement with Pre-Shared Key 405 -- 407 ori-keyAgreePSK ORI-TYPE ::= { 408 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 410 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 411 KeyAgreePSKRecipientInfo ::= SEQUENCE { 412 version CMSVersion, -- always set to 0 413 pskid PreSharedKeyIdentifier, 414 originator [0] EXPLICIT OriginatorIdentifierOrKey, 415 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 416 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 417 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 418 recipientEncryptedKeys RecipientEncryptedKeys } 420 END 422 6. Security Considerations 424 Implementations must protect the pre-shared key (PSK), key transport 425 private key, the agreement private key, the key-derivation key, and 426 the key-encryption key. Compromise of the PSK will make the 427 encrypted content vulnerable to the future invention of a large-scale 428 quantum computer. Compromise of the key transport private key or the 429 agreement private key may result in the disclosure of all contents 430 protected with that key. Compromise of the key-derivation key that 431 is established with the key transport private key or the agreement 432 private key may result in disclosure of the associated encrypted 433 content. Compromise of the key-encryption key may result in the 434 disclosure of all content-encryption keys or content-authenticated- 435 encryption keys that were protected with that key, which in turn may 436 result in the disclosure of the content. 438 A large-scale quantum computer will effectively cut the security 439 provided by a symmetric key algorithm in half. As a result, the PSK, 440 the key-derivation key, and the key-encryption key need at least 256 441 bits of entropy to provide 128 bits of security. For this reason, 442 these symmetric keys SHOULD be at least 256 bits in length. 444 Implementations must randomly generate key-derivation key as well as 445 the content-encryption key or content-authenticated-encryption key. 446 Also, the generation of public/private key pairs for the key 447 transport and key agreement algorithms rely on a random numbers. The 448 use of inadequate pseudo-random number generators (PRNGs) to generate 449 cryptographic keys can result in little or no security. An attacker 450 may find it much easier to reproduce the PRNG environment that 451 produced the keys, searching the resulting small set of 452 possibilities, rather than brute force searching the whole key space. 453 The generation of quality random numbers is difficult. [RFC4086] 454 offers important guidance in this area. 456 When using a key agreement algorithm, a key-encryption key is 457 produced to encrypt the content-encryption key or content- 458 authenticated-encryption key. If the key-encryption algorithm is 459 different that the algorithm used to protect the content, then the 460 effective security is determined by the weaker of the two algorithms. 461 If, for example, content is encrypted with 256-bit AES, and the key 462 is wrapped with 128-bit AES, then at most 128 bits of protection is 463 provided. Implementers must ensure that the key-encryption algorithm 464 is as strong or stronger than the content-encryption algorithm or 465 content-authenticated-encryption algorithm. 467 Implementers should not mix the quantum-resistant key management 468 algorithms with their non-quantum-resistant counterparts. That is, 469 the same content should not be protected with KeyTransRecipientInfo 470 and KeyTransPSKRecipientInfo, and the same content should not be 471 protected with KeyAgreeRecipientInfo and KeyAgreePSKRecipientInfo. 472 Doing so would make the content vulnerable to the future invention of 473 a large-scale quantum computer. 475 Implementer should not send the same content in different in separate 476 messages, one using a quantum-resistant key management algorithm and 477 the other using a non-quantum-resistant key management algorithm, 478 even if the content-encryption key is generated independently. Doing 479 so may allow an eavesdropper to correlate the messages, making the 480 content vulnerable to the future invention of a large-scale quantum 481 computer. 483 Implementers should be aware that cryptographic algorithms become 484 weaker with time. As new cryptoanalysis techniques are developed and 485 computing performance improves, the work factor to break a particular 486 cryptographic algorithm will be reduced. Therefore, cryptographic 487 algorithm implementations should be modular, allowing new algorithms 488 to be readily inserted. That is, implementors should be prepared for 489 the set of supported algorithms to change over time. 491 7. IANA Considerations 493 One object identifier for the ASN.1 module in the Section 5 was 494 assigned in the SMI Security for S/MIME Module Identifiers 495 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 497 id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { 498 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 499 pkcs-9(9) smime(16) mod(0) TBD0 } 501 One object identifier for an arc to assign Other Recipient Info 502 Identifiers was assigned in the SMI Security for S/MIME Mail Security 503 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 505 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 506 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 508 This assignment created the new SMI Security for Other Recipient Info 509 Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the 510 following two entries with references to this document: 512 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 513 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 514 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 516 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 517 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 518 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 520 8. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 526 Authenticated-Enveloped-Data Content Type", RFC 5083, 527 November 2007. 529 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 530 5652, September 2009. 532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 533 2119 Key Words", BCP 14, RFC 8174, May 2017. 535 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 536 One (ASN.1): Specification of basic notation", ITU-T 537 Recommendation X.680, 2015. 539 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 540 Specification of Basic Encoding Rules (BER), Canonical 541 Encoding Rules (CER) and Distinguished Encoding Rules 542 (DER)", ITU-T Recommendation X.690, 2015. 544 9. Informative References 546 [AES] National Institute of Standards and Technology, FIPS Pub 547 197: Advanced Encryption Standard (AES), 26 November 2001. 549 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 550 Quantum Cryptography", work-in-progress, draft-hoffman- 551 c2pq-02, August 2017. 553 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 554 numbers.xhtml#security-smime-0. 556 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 557 numbers.xhtml#security-smime. 559 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 560 numbers.xhtml#security-smime-13. 562 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 563 2631, June 1999. 565 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 566 Algorithm in Cryptographic Message Syntax (CMS)", RFC 567 3560, July 2003. 569 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 570 "Randomness Requirements for Security", RFC 4086, June 571 2005. 573 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 574 Cryptography (ECC) Algorithms in Cryptographic Message 575 Syntax (CMS)", RFC 5753, January 2010. 577 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 578 Expand Key Derivation Function (HKDF)", RFC 5869, May 579 2010. 581 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 582 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 583 June 2010. 585 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 586 Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, 587 June 2010. 589 Acknowledgements 591 Many thanks to Burt Kaliski, Jim Schaad, and Sean Turner for their 592 review and insightful comments. They have greatly improved the 593 design. 595 Author's Address 597 Russell Housley 598 Vigil Security, LLC 599 918 Spring Knoll Drive 600 Herndon, VA 20170 601 USA 602 EMail: housley@vigilsec.com