idnits 2.17.1 draft-housley-cms-mix-with-psk-04.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 179 has weird spacing: '...ivation funct...' -- The document date (3 April 2018) is 2186 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 421 -- Looks like a reference, but probably isn't: '1' on line 422 == Unused Reference: 'RFC3560' is defined on line 579, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-03 Summary: 0 errors (**), 0 flaws (~~), 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: 3 October 2018 3 April 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 . . . . . . . . . . . . . . . . . . . 7 64 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 68 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 Note that the CMS also supports key management techniques based on 111 symmetric key-encryption keys and passwords, but they are not 112 discussed in this document because they are already quantum 113 resistant. The symmetric key-encryption key technique is quantum 114 resistant when used with an adequate key size. The password 115 technique is quantum resistant when used with a quantum-resistant key 116 derivation function and a sufficiently large password. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 1.2. ASN.1 128 CMS values are generated using ASN.1 [X680], which uses the Basic 129 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 130 [X690]. 132 1.3. Version Numbers 134 The major data structures include a version number as the first item 135 in the data structure. The version number is intended to avoid ASN.1 136 decode errors. Some implementations do not check the version number 137 prior to attempting a decode, and then if a decode error occurs, the 138 version number is checked as part of the error handling routine. 139 This is a reasonable approach; it places error processing outside of 140 the fast path. This approach is also forgiving when an incorrect 141 version number is used by the sender. 143 Whenever the structure is updated, a higher version number will be 144 assigned. However, to ensure maximum interoperability, the higher 145 version number is only used when the new syntax feature is employed. 146 That is, the lowest version number that supports the generated syntax 147 is used. 149 2. Overview 151 The CMS enveloped-data content type [RFC5652] and the CMS 152 authenticated-enveloped-data content type [RFC5083] support both key 153 transport and key agreement public-key algorithms to establish the 154 key used to encrypt the content. In both cases, the sender randomly 155 generates the key, and then all recipients obtain that key. For 156 enveloped-data, a content-encryption key is established. For 157 authenticated-enveloped-data, a content-authenticated-encryption key 158 is established. All recipients use the sender-generated key for 159 decryption. 161 This specification defines two quantum-resistant ways to establish 162 these keys. In both cases, a PSK MUST be distributed to the sender 163 and all of the recipients by some out-of-band means that does not 164 make it vulnerable to the future invention of a large-scale quantum 165 computer, and an identifier MUST be assigned to the PSK. 167 The content-encryption key or content-authenticated-encryption key is 168 established by following these steps: 170 1. The content-encryption key or the content-authenticated-encryption 171 key is generated at random. 173 2. The key-derivation key is generated at random. 175 3. The key-encryption key is established for each recipient. The 176 details depend on the key management algorithm used: 178 key transport: the key-derivation key is encrypted in the 179 recipient's public key, then the key derivation function (KDF) 180 is used to mix the pre-shared key (PSK) and the key-derivation 181 key to produce the key-encryption key; or 183 key agreement: the recipient's public key and the sender's 184 private key are used to generate a pairwise symmetric key, then 185 the key derivation function (KDF) is used to mix the pre-shared 186 key (PSK) and the pairwise symmetric key to produce the key- 187 encryption key. 189 4. The key-encryption key is used to encrypt the content-encryption 190 key or content-authenticated-encryption key. 192 As specified in Section 6.2.5 of [RFC5652], recipient information for 193 additional key management techniques are represented in the 194 OtherRecipientInfo type. Two key management techniques are specified 195 in this document. Each of these is identified by a unique ASN.1 196 object identifier. 198 The first key management technique, called keyTransPSK, see 199 Section 3, uses a key transport algorithm to transfer the key- 200 derivation key from the sender to the recipient, and then the key- 201 derivation key is mixed with the PSK using a KDF. The output of the 202 KDF is the key-encryption key for the encryption of the content- 203 encryption key or content-authenticated-encryption key. 205 The second key management technique, called keyAgreePSK, see 206 Section 4, uses a key agreement algorithm to establish a pairwise 207 key-encryption key, which is used to encrypt the key-derivation key, 208 and the then key-derivation key is mixed with the PSK using a KDF. 209 The output of the KDF is the key-encryption key for the encryption of 210 the content-encryption key or content-authenticated-encryption key. 212 3. KeyTransPSKRecipientInfo 214 Per-recipient information using keyTransPSK is represented in the 215 KeyTransPSKRecipientInfo type, and its use is indicated by the id- 216 ori-keyTransPSK object identifier. Each instance of 217 KeyTransPSKRecipientInfo establishes the content-encryption key or 218 content-authenticated-encryption key for one or more recipients that 219 have access to the same PSK. 221 The id-ori-keyTransPSK object identifier is: 223 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 224 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 226 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 228 The KeyTransPSKRecipientInfo type is: 230 KeyTransPSKRecipientInfo ::= SEQUENCE { 231 version CMSVersion, -- always set to 0 232 pskid PreSharedKeyIdentifier, 233 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 234 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 235 ktris KeyTransRecipientInfos, 236 encryptedKey EncryptedKey } 238 PreSharedKeyIdentifier ::= OCTET STRING 240 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 242 The fields of the KeyTransPSKRecipientInfo type have the following 243 meanings: 245 version is the syntax version number. The version MUST be 0. The 246 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 248 pskid is the identifier of the PSK used by the sender. The 249 identifier is an OCTET STRING, and it need not be human readable. 251 kdfAlgorithm identifies the key-derivation algorithm, and any 252 associated parameters, used by the sender to mix the key- 253 derivation key and the PSK to generate the key-encryption key. 254 The KeyDerivationAlgorithmIdentifier is described in Section 255 10.1.6 of [RFC5652]. 257 keyEncryptionAlgorithm identifies a key-encryption algorithm used 258 to encrypt the content-encryption key. The 259 KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of 260 [RFC5652]. 262 ktris contains one KeyTransRecipientInfo type for each recipient; 263 it uses a key transport algorithm to establish the key-derivation 264 key. KeyTransRecipientInfo is described in Section 6.2.1 of 265 [RFC5652]. 267 encryptedKey is the result of encrypting the content-encryption 268 key or the content-authenticated-encryption key with the key- 269 encryption key. EncryptedKey is an OCTET STRING. 271 4. KeyAgreePSKRecipientInfo 273 Per-recipient information using keyAgreePSK is represented in the 274 KeyAgreePSKRecipientInfo type, and its use is indicated by the id- 275 ori-keyAgreePSK object identifier. Each instance of 276 KeyAgreePSKRecipientInfo establishes the content-encryption key or 277 content-authenticated-encryption key for one or more recipients that 278 have access to the same PSK. 280 The id-ori-keyAgreePSK object identifier is: 282 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 284 The KeyAgreePSKRecipientInfo type is: 286 KeyAgreePSKRecipientInfo ::= SEQUENCE { 287 version CMSVersion, -- always set to 0 288 pskid PreSharedKeyIdentifier, 289 originator [0] EXPLICIT OriginatorIdentifierOrKey, 290 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 291 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 292 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 293 recipientEncryptedKeys RecipientEncryptedKeys } 295 The fields of the KeyAgreePSKRecipientInfo type have the following 296 meanings: 298 version is the syntax version number. The version MUST be 0. The 299 CMSVersion type is described in Section 10.2.5 of [RFC5652]. 301 pskid is the identifier of the PSK used by the sender. The 302 identifier is an OCTET STRING, and it need not be human readable. 304 originator is a CHOICE with three alternatives specifying the 305 sender's key agreement public key. Implementations MUST support 306 all three alternatives for specifying the sender's public key. 307 The sender uses the corresponding private key and the recipient's 308 public key to generate a pairwise key. A key derivation function 309 (KDF) is used to mix the PSK and the pairwise key to produce a 310 key-encryption key. The OriginatorIdentifierOrKey type is 311 described in Section 6.2.2 of [RFC5652]. 313 ukm is optional. With some key agreement algorithms, the sender 314 provides a User Keying Material (UKM) to ensure that a different 315 key is generated each time the same two parties generate a 316 pairwise key. Implementations MUST accept a 317 KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. 318 Implementations that do not support key agreement algorithms that 319 make use of UKMs MUST gracefully handle the presence of UKMs. The 320 UserKeyingMaterial type is described in Section 10.2.6 of 321 [RFC5652]. 323 kdfAlgorithm identifies the key-derivation algorithm, and any 324 associated parameters, used by the sender to mix the pairwise key 325 and the PSK. The KeyDerivationAlgorithmIdentifier is described in 326 Section 10.1.6 of [RFC5652]. 328 keyEncryptionAlgorithm identifies a key-encryption algorithm used 329 to encrypt the content-encryption key or the content- 330 authenticated-encryption key. The 331 KeyEncryptionAlgorithmIdentifier type is described in Section 332 10.1.3 of [RFC5652]. 334 recipientEncryptedKeys includes a recipient identifier and 335 encrypted key for one or more recipients. The 336 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 337 specifying the recipient's certificate, and thereby the 338 recipient's public key, that was used by the sender to generate a 339 pairwise key. The encryptedKey is the result of encrypting the 340 content-encryption key or the content-authenticated-encryption key 341 with the key-encryption key. EncryptedKey is an OCTET STRING. 342 The RecipientEncryptedKeys type is defined in Section 6.2.2 of 343 [RFC5652]. 345 5. ASN.1 Module 347 This section contains the ASN.1 module for the two key management 348 techniques defined in this document. This module imports types from 349 other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. 351 CMSORIforPSK-2017 352 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 353 smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) } 355 DEFINITIONS IMPLICIT TAGS ::= 356 BEGIN 358 -- EXPORTS All 360 IMPORTS 362 AlgorithmIdentifier{}, KEY-DERIVATION 363 FROM AlgorithmInformation-2009 -- [RFC5912] 364 { iso(1) identified-organization(3) dod(6) internet(1) 365 security(5) mechanisms(5) pkix(7) id-mod(0) 366 id-mod-algorithmInformation-02(58) } 368 OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, 369 KeyTransRecipientInfo, OriginatorIdentifierOrKey, 370 UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, 371 KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier 372 FROM CryptographicMessageSyntax-2009 -- [RFC5911] 373 { iso(1) member-body(2) us(840) rsadsi(113549) 374 pkcs(1) pkcs-9(9) smime(16) modules(0) 375 id-mod-cms-2004-02(41) } ; 377 -- 378 -- OtherRecipientInfo Types (ori-) 379 -- 381 SupportedOtherRecipInfo OTHER-RECIPIENT ::= { 382 ori-keyTransPSK | 383 ori-keyAgreePSK, 384 ... } 386 -- 387 -- Key Transport with Pre-Shared Key 388 -- 390 ori-keyTransPSK OTHER-RECIPIENT ::= { 391 KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } 393 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 394 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 396 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } 398 KeyTransPSKRecipientInfo ::= SEQUENCE { 399 version CMSVersion, -- always set to 0 400 pskid PreSharedKeyIdentifier, 401 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 402 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 403 ktris KeyTransRecipientInfos, 404 encryptedKey EncryptedKey } 406 PreSharedKeyIdentifier ::= OCTET STRING 408 KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo 409 -- 410 -- Key Agreement with Pre-Shared Key 411 -- 413 ori-keyAgreePSK ORI-TYPE ::= { 414 KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } 416 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } 418 KeyAgreePSKRecipientInfo ::= SEQUENCE { 419 version CMSVersion, -- always set to 0 420 pskid PreSharedKeyIdentifier, 421 originator [0] EXPLICIT OriginatorIdentifierOrKey, 422 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 423 kdfAlgorithm KeyDerivationAlgorithmIdentifier, 424 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 425 recipientEncryptedKeys RecipientEncryptedKeys } 427 END 429 6. Security Considerations 431 Implementations must protect the pre-shared key (PSK), key transport 432 private key, the agreement private key, the key-derivation key, and 433 the key-encryption key. Compromise of the PSK will make the 434 encrypted content vulnerable to the future invention of a large-scale 435 quantum computer. Compromise of the PSK and either the key transport 436 private key or the agreement private key may result in the disclosure 437 of all contents protected with that combination of keying material. 438 Compromise of the PSK and the key-derivation key may result in 439 disclosure of all contents protected with that combination of keying 440 material. Compromise of the key-encryption key may result in the 441 disclosure of all content-encryption keys or content-authenticated- 442 encryption keys that were protected with that keying materail, which 443 in turn may result in the disclosure of the content. 445 A large-scale quantum computer will essentially negate the security 446 provided by the key transport algorithm or the key agreement 447 algorithm, which means that the attacker with a large-scale quantum 448 computer can discover the key-derivation key. In addition a large- 449 scale quantum computer effectively cuts the security provided by a 450 symmetric key algorithm in half. Therefore, the PSK needs at least 451 256 bits of entropy to provide 128 bits of security. To match that 452 same level of security, the key derivation function needs to be 453 quantum-resistant and produce a key-encryption key that is at least 454 256 bits in length. Similarly, the content-encryption key or 455 content-authenticated-encryption key needs to be at least 256 bits in 456 length. 458 Implementations must randomly generate key-derivation keys as well as 459 the content-encryption keys or content-authenticated-encryption keys. 460 Also, the generation of public/private key pairs for the key 461 transport and key agreement algorithms rely on a random numbers. The 462 use of inadequate pseudo-random number generators (PRNGs) to generate 463 cryptographic keys can result in little or no security. An attacker 464 may find it much easier to reproduce the PRNG environment that 465 produced the keys, searching the resulting small set of 466 possibilities, rather than brute force searching the whole key space. 467 The generation of quality random numbers is difficult. [RFC4086] 468 offers important guidance in this area. 470 When using a PSK with a key transport or a key agreement algorithm, a 471 key-encryption key is produced to encrypt the content-encryption key 472 or content-authenticated-encryption key. If the key-encryption 473 algorithm is different than the algorithm used to protect the 474 content, then the effective security is determined by the weaker of 475 the two algorithms. If, for example, content is encrypted with 476 256-bit AES, and the key is wrapped with 128-bit AES, then at most 477 128 bits of protection is provided. Implementers must ensure that 478 the key-encryption algorithm is as strong or stronger than the 479 content-encryption algorithm or content-authenticated-encryption 480 algorithm. 482 Implementers SHOULD NOT mix quantum-resistant key management 483 algorithms with their non-quantum-resistant counterparts. For 484 example, the same content should not be protected with 485 KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the 486 same content should not be protected with KeyAgreeRecipientInfo and 487 KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable 488 to the future invention of a large-scale quantum computer. 490 Implementers should not send the same content in different messages, 491 one using a quantum-resistant key management algorithm and the other 492 using a non-quantum-resistant key management algorithm, even if the 493 content-encryption key is generated independently. Doing so may 494 allow an eavesdropper to correlate the messages, making the content 495 vulnerable to the future invention of a large-scale quantum computer. 497 Implementers should be aware that cryptographic algorithms become 498 weaker with time. As new cryptoanalysis techniques are developed and 499 computing performance improves, the work factor to break a particular 500 cryptographic algorithm will be reduced. Therefore, cryptographic 501 algorithm implementations should be modular, allowing new algorithms 502 to be readily inserted. That is, implementors should be prepared for 503 the set of supported algorithms to change over time. 505 7. IANA Considerations 507 One object identifier for the ASN.1 module in the Section 5 was 508 assigned in the SMI Security for S/MIME Module Identifiers 509 (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: 511 id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { 512 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 513 pkcs-9(9) smime(16) mod(0) TBD0 } 515 One object identifier for an arc to assign Other Recipient Info 516 Identifiers was assigned in the SMI Security for S/MIME Mail Security 517 (1.2.840.113549.1.9.16) [IANA-SMIME] registry: 519 id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 520 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } 522 This assignment created the new SMI Security for Other Recipient Info 523 Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the 524 following two entries with references to this document: 526 id-ori-keyTransPSK OBJECT IDENTIFIER ::= { 527 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 528 pkcs-9(9) smime(16) id-ori(TBD1) 1 } 530 id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { 531 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 532 pkcs-9(9) smime(16) id-ori(TBD1) 2 } 534 8. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 540 Authenticated-Enveloped-Data Content Type", RFC 5083, 541 November 2007. 543 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 544 5652, September 2009. 546 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 547 2119 Key Words", BCP 14, RFC 8174, May 2017. 549 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 550 One (ASN.1): Specification of basic notation", ITU-T 551 Recommendation X.680, 2015. 553 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 554 Specification of Basic Encoding Rules (BER), Canonical 555 Encoding Rules (CER) and Distinguished Encoding Rules 556 (DER)", ITU-T Recommendation X.690, 2015. 558 9. Informative References 560 [AES] National Institute of Standards and Technology, FIPS Pub 561 197: Advanced Encryption Standard (AES), 26 November 2001. 563 [C2PQ] Hoffman, P., "The Transition from Classical to Post- 564 Quantum Cryptography", work-in-progress, draft-hoffman- 565 c2pq-03, February 2018. 567 [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- 568 numbers.xhtml#security-smime-0. 570 [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- 571 numbers.xhtml#security-smime. 573 [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- 574 numbers.xhtml#security-smime-13. 576 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 577 2631, June 1999. 579 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 580 Algorithm in Cryptographic Message Syntax (CMS)", RFC 581 3560, July 2003. 583 [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, 584 "Randomness Requirements for Security", RFC 4086, June 585 2005. 587 [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve 588 Cryptography (ECC) Algorithms in Cryptographic Message 589 Syntax (CMS)", RFC 5753, January 2010. 591 [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 592 Expand Key Derivation Function (HKDF)", RFC 5869, May 593 2010. 595 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 596 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 597 June 2010. 599 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 600 Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, 601 June 2010. 603 Acknowledgements 605 Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean 606 Turner, and Daniel Van Geest for their review and insightful 607 comments. They have greatly improved the design and implementation 608 guidance. 610 Author's Address 612 Russell Housley 613 Vigil Security, LLC 614 918 Spring Knoll Drive 615 Herndon, VA 20170 616 USA 617 EMail: housley@vigilsec.com