idnits 2.17.1 draft-ietf-smime-cms-rsa-kem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Unrecognized Status in 'Category: Standards', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7651 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 section? 'STDWORDS' on line 48 looks like a reference -- Missing reference section? 'PKCS1' on line 664 looks like a reference -- Missing reference section? 'ISO-IEC-18033-2' on line 97 looks like a reference -- Missing reference section? 'NESSIE' on line 98 looks like a reference -- Missing reference section? 'SHOUP' on line 185 looks like a reference -- Missing reference section? 'CMS' on line 114 looks like a reference -- Missing reference section? 'CMSALGS' on line 120 looks like a reference -- Missing reference section? 'CMS-OAEP' on line 122 looks like a reference -- Missing reference section? 'NIST-SHA2' on line 140 looks like a reference -- Missing reference section? 'AES-WRAP' on line 676 looks like a reference -- Missing reference section? '3DES-WRAP' on line 684 looks like a reference -- Missing reference section? 'NIST-GUIDELINES' on line 194 looks like a reference -- Missing reference section? 'RANDOM' on line 219 looks like a reference -- Missing reference section? '0' on line 707 looks like a reference -- Missing reference section? '1' on line 722 looks like a reference -- Missing reference section? '2' on line 725 looks like a reference -- Missing reference section? 'NIST-SCHEMES' on line 630 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group B. Kaliski 3 Internet Draft RSA Laboratories 4 Document: draft-ietf-smime-cms-rsa-kem-00.txt May 2003 5 Category: Standards 7 Use of the RSA-KEM Key Transport Algorithm in CMS 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Comments or suggestions for improvement may be made on the "ietf- 32 smime" mailing list, or directly to the author. 34 Abstract 36 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- 37 forward) mechanism for transporting keying data to a recipient using 38 the recipient's RSA public key. This document specifies the 39 conventions for using the RSA-KEM Key Transport Algorithm with the 40 Cryptographic Message Syntax (CMS). 42 Conventions Used in This Document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC 2119 47 [STDWORDS]. 49 1. Introduction 51 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- 52 forward) mechanism for transporting keying data to a recipient using 53 the recipient's RSA public key. 55 Most previous key transport algorithms based on the RSA public-key 56 cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have 57 the following general form: 59 1. Format or "pad" the keying data to obtain an integer m. 61 2. Encrypt the integer m with the recipient's RSA public key: 63 c = m^e mod n 65 3. Output c as the encrypted keying data. 67 The RSA-KEM Key Transport Algorithm takes a different approach that 68 provides higher security assurance, by encrypting a _random_ integer 69 with the recipient's public key, and using a symmetric key wrapping 70 scheme to encrypt the keying data. It has the following form: 72 1. Generate a random integer z between 0 and n-1. 74 2. Encrypt the integer z with the recipient's RSA public key: 76 c = z^e mod n. 78 3. Derive a key-encrypting key KEK from the integer z. 80 4. Wrap the keying data using KEK to obtain wrapped keying data 81 KD. 83 5. Output c and KD as the encrypted keying data. 85 This different approach provides higher security assurance because 86 the input to the underlying RSA operation is random and independent 87 of the message, and the key-encrypting key KEK is derived from it in 88 a strong way. As a result, the algorithm enjoys a "tight" security 89 proof in the random oracle model. It is also architecturally 90 convenient because the public-key operations are separate from the 91 symmetric operations on the keying data. One benefit is that the 92 length of the keying data is bounded only by the symmetric key 93 wrapping scheme, not the size of the RSA modulus. 95 The RSA-KEM Key Transport Algorithm in various forms is being 96 adopted in several draft standards including ANSI X9.44 [ANSI-X9.44] 97 and ISO/IEC 18033-2 [ISO-IEC-18033-2]. It has also been recommended 98 by the NESSIE project [NESSIE]. Although the other standards are 99 still in development, the algorithm is fairly stable across the 100 drafts. For completeness, a specification of the algorithm is given 101 in Appendix A of this document; ASN.1 syntax is given in Appendix B. 103 NOTE: The term KEM stands for "key encapsulation mechanism" and 104 refers to the first three steps of the process above. The 105 formalization of key transport algorithms (or more generally, 106 asymmetric encryption schemes) in terms of key encapsulation 107 mechanisms is a result of research by Victor Shoup leading to the 108 development of the ISO/IEC 18033-2 standard [SHOUP]. 110 2. Use in CMS 112 The RSA-KEM Key Transport Algorithm MAY be employed for one or more 113 recipients in the CMS enveloped-data content type (Section 6 of 114 [CMS]), where the keying data processed by the algorithm is the CMS 115 content-encryption key. 117 The RSA-KEM Key Transport Algorithm SHOULD be considered for new 118 CMS-based applications as a replacement for the widely implemented 119 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see 120 [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to 121 chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm 122 has also been proposed as a replacement (see [PKCS1] and [CMS- 123 OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter 124 security proof, but the disadvantage of slightly longer encrypted 125 keying data. 127 2.1 Underlying Components 129 A CMS implementation that supports the RSA-KEM Key Transport 130 Algorithm MUST support at least the following underlying components: 132 * For the key derivation function, KDF2 (see [ANSI-X9.44][IEEE- 133 P1363a]) based on SHA-1 (see [NIST-SHA2]) (this function is 134 also specified as the key derivation function in [ANSI-X9.63]) 136 * For the key wrapping scheme, AES-Wrap-128, i.e., the AES Key 137 Wrap with a 128-bit key encrypting key (see [AES-WRAP]) 139 An implementation SHOULD also support KDF2 based on SHA-256 (see 140 [NIST-SHA2]), and the Triple-DES Key Wrap (see [3DES-WRAP]). It MAY 141 support other underlying components. 143 2.2 RecipientInfo Conventions 145 When the RSA-KEM Key Transport Algorithm is employed for a 146 recipient, the RecipientInfo alternative for that recipient MUST be 147 KeyTransRecipientInfo. The algorithm-specific fields of the 148 KeyTransRecipientInfo value MUST have the following values: 150 * keyEncryptionAlgorithm.algorithm MUST be id-kts2-basic (see 151 Appendix B) 153 * keyEncryptionAlgorithm.parameters MUST be a value of type 154 KTS2-Parms (see Appendix B) 156 * encryptedKey MUST be the encrypted keying data output by the 157 algorithm (see Appendix A) 159 2.3 Certificate Conventions 161 A recipient who employs the RSA-KEM Key Transport Algorithm MAY 162 identify the public key in a certificate by the same 163 AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using 164 the rsaEncryption object identifier [PKCS1]. 166 If the recipient wishes only to employ the RSA-KEM Key Transport 167 Algorithm with a given public key, the recipient MUST identify the 168 public key in the certificate using the id-kts2-basic object 169 identifier (see Appendix B) where the KTS2-Params value indicates 170 the underlying components with which the algorithm is to be 171 employed. 173 [[matching rules to be added]] 175 2.4 SMIMECapabilities Attribute Conventions 177 [[to be added]] 179 3. Security Considerations 181 The security of the RSA-KEM Key Transport Algorithm described in 182 this document has been shown to be tightly related to the difficulty 183 of either solving the RSA problem or breaking the underlying 184 symmetric key wrapping scheme, if the underlying key derivation 185 function is modeled as a random oracle [SHOUP]. While in practice a 186 random-oracle result does not provide an actual security proof for 187 any particular key derivation function, the result does provide 188 assurance that the general construction is reasonable; a key 189 derivation function would need to be particularly weak to lead to an 190 attack that is not possible in the random oracle model. 192 The RSA key size and the underlying components should be selected 193 consistent with the desired symmetric security level for an 194 application. Several security levels have been identified in [NIST- 195 GUIDELINES]. For brevity, the first three levels are mentioned here: 197 * 80-bit security. The RSA key size SHOULD be at least 1024 198 bits, the hash function underlying KDF2 SHOULD be SHA-1 or 199 above, and the symmetric key-wrapping scheme SHOULD be AES Key 200 Wrap or Triple-DES Key Wrap. 202 * 112-bit security. The RSA key size SHOULD be at least 2048 203 bits, the hash function underlying KDF2 SHOULD be SHA-224 or 204 above, and the symmetric key-wrapping scheme SHOULD be AES Key 205 Wrap or Triple-DES Key Wrap. 207 * 128-bit security. The RSA key size SHOULD be at least 3072 208 bits, the hash function underlying KDF2 SHOULD be SHA-256 or 209 above, and the symmetric key-wrapping scheme SHOULD be AES Key 210 Wrap. 212 Note that the AES Key Wrap MAY be used at all three of these levels; 213 the use of AES does not require a 128-bit security level for other 214 components. 216 The security of the algorithm also depends on the strength of the 217 random number generator, which SHOULD have a comparable security 218 level. For further discussion on random number generation, please 219 see [RANDOM]. 221 Implementations SHOULD NOT reveal information about intermediate 222 values or calculations, whether by timing or other "side channels", 223 or otherwise an opponent may be able to determine information about 224 the keying data and/or the recipient's private key. Although not all 225 intermediate information may be useful to an opponent, it is 226 preferable to conceal as much information as is it practical to, 227 unless analysis specifically indicates that the information would 228 not be useful. 230 Parties MAY wish to formalize the assurance that one another's 231 implementations are correct through implementation validation, e.g. 232 NIST's Cryptographic Module Validation Program (CMVP). 234 4. References 236 4.1 Normative References 238 3DES-WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC 239 3217. December 2001. 241 AES-WRAP Schaad, J. and R. Housley. Advanced Encryption 242 Standard (AES) Key Wrap Algorithm. RFC 3394. 243 September 2002. 245 ANSI-X9.63 American National Standard X9.63-2002: Public Key 246 Cryptography for the Financial Services Industry: 247 Key Agreement and Key Transport Using Elliptic 248 Curve Cryptography. 250 CMS Housley, R. Cryptographic Message Syntax. RFC 251 3369. August 2002. 253 CMSALGS Housley, R. Cryptographic Message Syntax (CMS) 254 Algorithms. RFC 3370. August 2002. 256 NIST-SHA2 National Institute of Standards and Technology 257 (NIST). FIPS 180-2: Secure Hash Standard. August 258 2002. 260 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 261 Requirement Levels. RFC 2119. March 1997. 263 4.2 Informative References 265 ANSI-X9.44 ANSI X9F1 Working Group. ANSI X9.44: Public Key 266 Cryptography for the Financial Services Industry - 267 - Key Establishment Using Integer Factorization 268 Cryptography. Draft D4.1, April 1, 2003. 270 CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport 271 Algorithm in CMS. Internet Draft . December 2002. 274 IEEE-P1363a IEEE P1363 Working Group. IEEE P1363a: Standard 275 Specifications for Public Key Cryptography: 276 Additional Techniques. Draft D12, May 12, 2003. 277 Available via http://grouper.ieee.org/groups/1363. 279 ISO-IEC-18033-2 ISO/IEC 18033-2: Information technology -- 280 Security techniques -- Encryption algorithms -- 281 Part 2: Asymmetric Ciphers. Committee Draft, 282 December 18, 2002. 284 NESSIE NESSIE Consortium. Portfolio of Recommended 285 Cryptographic Primitives. February 27, 2003. 286 Available via http://www.cryptonessie.org/. 288 NIST-GUIDELINES National Institute of Standards and Technology. 289 Special Publication 800-57: Recommendation for Key 290 Management. Part 1: General Guideline. Draft, 291 January 2003. Available via 292 http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. 294 NIST-SCHEMES National Institute of Standards and Technology. 295 Special Publication 800-56: Recommendation on Key 296 Establishment Schemes. Draft 2.0, January 2003. 297 Available via 298 http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. 300 PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA 301 Cryptography Specifications Version 2.1. RFC 3447. 302 February 2003. 304 RANDOM Eastlake, D., S. Crocker, and J. Schiller. 305 Randomness Recommendations for Security. RFC 1750. 306 December 1994. 308 SHOUP Shoup, V. A Proposal for an ISO Standard for 309 Public Key Encryption. Version 2.1, December 20, 310 2001. Available via http://www.shoup.net/papers/. 312 5. IANA Considerations 314 Within the CMS, algorithms are identified by object identifiers 315 (OIDs). All of the OIDs used in this document were assigned in 316 Public-Key Cryptography Standards (PKCS) documents, Accredited 317 Standards Committee (ASC) X9 documents, or by the National Institute 318 of Standards and Technology (NIST). No further action by the IANA is 319 necessary for this document or any anticipated updates. 321 6. Acknowledgments 323 This document is one part of a strategy to align algorithm standards 324 produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. I would 325 like to thank the members of the ANSI X9F1 working group for their 326 contributions to drafts of ANSI X9.44 which led to this 327 specification. My thanks as well to Russ Housley as well for his 328 guidance and encouragement. 330 7. Author Address 332 Burt Kaliski 333 RSA Laboratories 334 174 Middlesex Turnpike 335 Bedford, MA 01730 336 USA 337 bkaliski@rsasecurity.com 339 Appendix A. RSA-KEM Key Transport Algorithm 341 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- 342 forward) mechanism for transporting keying data to a recipient using 343 the recipient's RSA public key. 345 With this type of algorithm, a sender encrypts the keying data using 346 the recipient's public key to obtain encrypted keying data. The 347 recipient decrypts the encrypted keying data using the recipient's 348 private key to recover the keying data. 350 A.1 Underlying Components 352 The algorithm has the following underlying components: 354 * KDF, a key derivation function, which derives keying data of a 355 specified length from a shared secret value 357 * Wrap, a symmetric key wrapping scheme, which encrypts keying 358 data using a key-encrypting key 360 In the following, kekLen denotes the length in bytes of the key- 361 encrypting key for the underlying symmetric key-wrapping scheme. 363 In this scheme, the length of the keying data to be transported MUST 364 be among the lengths supported by the underlying symmetric key 365 wrapping scheme. (The AES Key Wrap, for instance, requires the 366 length of the keying data to be a multiple of 8 bytes, and at least 367 16 bytes.) Usage and formatting of the keying data (e.g., parity 368 adjustment for Triple-DES keys) is outside the scope of this 369 algorithm. 371 With some key derivation functions, it is possible to include other 372 information besides the shared secret value in the input to the 373 function. Also, with some symmetric key wrapping schemes, it is 374 possible to associate a label with the keying data. Such uses are 375 outside the scope of this document, as they are not directly 376 supported by CMS. 378 A.2 Sender's Operations 380 Let (n,e) be the recipient's RSA public key (see [PKCS1] for 381 details) and let K be the keying data to be transported. 383 Let nLen denote the length in bytes of the modulus n, i.e., the 384 least integer such that 2^{8*nLen} > n. 386 The sender performs the following operations: 388 1. Generate a random integer z between 0 and n-1 (see Note), and 389 convert z to a byte string Z of length nLen, most significant 390 byte first: 392 z = RandomInteger (0, n-1) 393 Z = IntegerToString (z, nLen) 395 2. Encrypt the random integer z using the recipient's public key 396 (n,e) and convert the resulting integer c to a ciphertext C, a 397 byte string of length nLen: 399 c = z^e mod n 400 C = IntegerToString (c, nLen) 402 3. Derive a key-encrypting key KEK of length kekLen bytes from 403 the byte string Z using the underlying key derivation 404 function: 406 KEK = KDF (Z, kekLen) 408 4. Wrap the keying data K using the underlying key wrapping 409 scheme with the key-encrypting key KEK to obtain wrapped 410 keying data WK: 412 WK = Wrap (KEK, K) 414 5. Concatenate the ciphertext C and the wrapped keying data WK to 415 obtain the encrypted keying data EK: 417 EK = C || WK 419 6. Output the encrypted keying data EK. 421 NOTE: The random integer z MUST be generated independently at random 422 for different encryption operations, whether for the same or 423 different recipients. 425 A.3 Recipient's Operations 427 Let (n,d) be the recipient's RSA private key (see [PKCS1]; other 428 private key formats are allowed) and let EK be the encrypted keying 429 data. 431 Let nLen denote the length in bytes of the modulus n. 433 The recipient performs the following operations: 435 1. Separate the encrypted keying data EK into a ciphertext C of 436 length nLen bytes and wrapped keying data WK: 438 C || WK = EK 440 If the length of the encrypted keying data is less than nLen 441 bytes, output "decryption error" and stop. 443 2. Convert the ciphertext C to an integer c, most significant 444 byte first. Decrypt the integer c using the recipient's 445 private key (n,d) to recover an integer z (see Note): 447 c = StringToInteger (C) 448 z = c^d mod n 450 If the integer c is not between 0 and n-1, output "decryption 451 error" and stop. 453 3. Convert the integer z to a byte string Z of length nLen, most 454 significant byte first (see Note): 456 Z = IntegerToString (z, nLen) 458 4. Derive a key-encrypting key KEK of length kekLen bytes from 459 the byte string Z using the underlying key derivation function 460 (see Note): 462 KEK = KDF (Z, kekLen) 464 5. Unwrap the wrapped keying data WK using the underlying key 465 wrapping scheme with the key-encrypting key KEK to recover the 467 keying data K: 469 K = Unwrap (KEK, WK) 471 If the unwrapping operation outputs an error, output 472 "decryption error" and stop. 474 6. Output the keying data K. 476 NOTE: Implementations SHOULD NOT reveal information about the 477 integer z and the string Z, nor about the calculation of the 478 exponentiation in Step 2, the conversion in Step 3, or the key 479 derivation in Step 4, whether by timing or other "side channels". 480 The observable behavior of the implementation SHOULD be the same at 481 these steps for all ciphertexts C that are in range. (For example, 482 IntegerToString conversion should take the same amount of time 483 regardless of the actual value of the integer z.) The integer z, the 484 string Z and other intemediate results MUST be securely deleted when 485 they are no longer needed. 487 Appendix B. ASN.1 Syntax 489 The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm 490 is a special case of the syntax for Key Transport Scheme 2 (KTS2) in 491 the draft ANSI X9.44 [ANSI-X9.44]. The syntax for the scheme is 492 given in Section B.1. The syntax for selected underlying components 493 including those mentioned above is given in B.2. 495 The following object identifier prefixes are used in the definitions 496 below: 498 x9-44 OID ::= { 499 iso(1) identified-organization(3) tc68(133) country(16) 500 x9(840) x9Standards(9) x9-44(44) 501 } 503 pkcs-1 OID ::= { 504 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 505 } 507 nistAlgorithm OID ::= { 508 joint-iso-itu-t(2) country(16) us(840) organization(1) 509 gov(101) csor(3) nistAlgorithm(4) 510 } 512 The material in this Appendix is based on a draft standard and is 513 SUBJECT TO CHANGE as that standard is developed. 515 B.1 RSA-KEM Key Transport Algorithm 517 The object identifier for the RSA-KEM Key Transport Algorithm is the 518 same as for the basic KTS2 scheme in the draft ANSI X9.44, id-kts2- 519 basic, which is defined in the draft as 521 id-kts2-basic OID ::= { x9-44 schemes(2) kts2-basic(7) } 523 The associated parameters for id-kts2-basic have type KTS2-Parms: 525 KTS2-Parms ::= SEQUENCE { 526 kas [0] KTS2-KeyAgreementScheme, 527 kws [1] KTS2-SymmetricKeyWrappingScheme, 528 labelMethod [2] KTS2-LabelMethod 529 } 531 The fields of type KTS2-Parms have the following meanings: 533 * kas identifies the underlying key agreement scheme. For the 534 RSA-KEM Key Transport Algorithm, the scheme is the basic Key 535 Agreement Scheme 1 (KAS1) from the draft ANSI X9.44. 537 The object identifier for the basic KAS1 is id-kas1-basic, 538 which is defined in the draft ANSI X9.44 as 540 id-kas1-basic OID ::= { x9-44 schemes(2) kas1-basic(1) } 542 The associated parameters for id-kas1-basic have type KAS1- 543 Parms: 545 KAS1-Parms ::= SEQUENCE { 546 sves [0] KAS1-SecretValueEncapsulationScheme, 547 kdf [1] KAS1-KeyDerivationFunction, 548 otherInfoMethod [2] KAS1-OtherInfoMethod 549 } 551 The fields of type KAS1-Parms have the following meanings: 553 * sves identifies the underlying secret-value 554 encapsulation mechanism. (In the draft ANSI X9.44, the 555 term "Secret Value Encapsulation Scheme" refers to the 556 first _two_ steps of the RSA-KEM Key Transport 557 Algorithm, which are separated from the key derivation 558 function for architectural reasons.) For the RSA-KEM Key 559 Transport Algorithm, the mechanism is RSASVES1 from the 560 draft ANSI X9.44. 562 The object identifier for RSASVES1 is id-rsasves1, which 563 is defined in the draft ANSI X9.44 as 565 id-rsasves1 OID ::= { 566 x9-44 components(1) rsasves1(2) 567 } 569 This object identifier has no associated parameters. 571 * kdf identifies the underlying key derivation function. 572 For alignment with the draft ANSI X9.44, it MUST be 573 KDF2. However, other key derivation functions MAY be 574 used with CMS. Please see B.2.1 for the syntax for KDF2. 576 KAS1-KeyDerivationFunction ::= AlgorithmIdentifier 578 * otherInfoMethod specifies the method for formatting 579 other information to be included in the input to the key 580 derivation function. For this version of the document, 581 the method MUST be the "specified other information" 582 method. 584 KAS1-OtherInfoMethod ::= AlgorithmIdentifier 586 The object identifier for the "specified other 587 information" method is id-specifiedOtherInfo: 589 id-specifiedOtherInfo OID ::= [[to be defined]] 591 The associated parameters for id-specifiedOtherInfo have 592 type SpecifiedOtherInfo: 594 SpecifiedOtherInfo ::= OCTET STRING SIZE((0..MAX)) 596 For this version of the document, the value of the other 597 information MUST be the empty string. 599 * kws identifies the underlying symmetric key-wrapping scheme. 600 For alignment with the draft ANSI X9.44, it MUST be an X9- 601 approved symmetric key-wrapping scheme. (See Note.) However, 602 other schemes MAY be used with CMS. Please see B.2.2 for the 603 syntax for the AES and Triple-DES Key Wraps. 605 KTS2-SymmetricKeyWrappingScheme ::= AlgorithmIdentifier 607 * labelMethod specifies the method for formatting a label to be 608 associated with the keying data. For this version of the 609 document, the method MUST be the "specified label" method. 611 KTS2-LabelMethod ::= AlgorithmIdentifier 613 The object identifier for the "specified label" method is id- 614 specifiedLabel, which is defined in the draft ANSI X9.44 as 616 id-specifiedLabel OID ::= { pkcs-1 specifiedLabel(9) } 618 The associated parameters for id-specifiedLabel have type 619 SpecifiedLabel: 621 SpecifiedLabel ::= OCTET STRING SIZE((0..MAX)) 623 For this version of the document, the value of the label MUST 624 be the empty string. 626 NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key 627 Wrap are in the process of being approved by X9. 629 DISCUSSION TOPIC: In NIST's key establishment schemes recommendation 630 [NIST-SCHEMES], the parties' names are included in the "other 631 information" for key derivation. Should they be included here as 632 well? 634 B.2 Selected Underlying Components 636 B.2.1 Key Derivation Functions 638 The object identifier for KDF2 (see [ANSI-X9.44]) is 640 id-kdf2 OID ::= { x9-44 components(1) kdf2(1) } 642 The associated parameters identify the underlying hash function. For 643 alignment with the draft ANSI X9.44, the hash function MUST be an 644 X9-approved hash function. (See Note.) However, other hash functions 645 MAY be used with CMS. 647 KDF2-Parms ::= AlgorithmIdentifier 649 The object identifier for SHA-1 is 651 id-sha1 OID ::= { 652 iso(1) identified-organization(3) oiw(14) secsig(3) 653 algorithms(2) sha1(26) 654 } 656 The object identifiers for SHA-256, SHA-384 and SHA-512 are 658 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 659 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 660 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 662 There has been some confusion over whether the various SHA object 663 identifiers have a NULL parameter, or no associated parameters. As 664 also discussed in [PKCS1], implementations SHOULD generate algorithm 665 identifiers without parameters, and MUST accept algorithm 666 identifiers either without parameters, or with NULL parameters. 668 NOTE: As of this writing, only SHA-1 is an X9-approved hash 669 function; SHA-224 and above are in the process of being approved. 670 The object identifier for SHA-224 has not yet been assigned. 672 B.2.2 Symmetric Key Wrapping Schemes 674 The object identifier for the AES Key Wrap depends on the size of 675 the key encrypting key. There are three object identifiers (see 676 [AES-WRAP]): 678 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 679 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 680 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 682 These object identifiers have no associated parameters. 684 The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) 685 is 687 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 688 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 689 smime(16) alg(3) 6 690 } 692 This object identifier has a NULL parameter. 694 B.3 Example 696 As an example, if the key derivation function is KDF2 based on SHA-1 697 and the symmetric key wrapping scheme is the AES Key Wrap with a 698 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport 699 Algorithm will have the following value: 701 SEQUENCE { 702 id-kts2-basic, -- basic KTS2 703 SEQUENCE { -- KTS2-Parms 704 [0] SEQUENCE { -- key agreement scheme 705 id-kas1-basic, -- basic KAS1 706 SEQUENCE { -- KAS1-Parms 707 [0] SEQUENCE { -- secret value encapsulation scheme 708 id-rsasves1 -- RSASVES1; no parameters 709 }, 710 [1] SEQUENCE { -- key derivation function 711 id-kdf2, -- KDF2 712 SEQUENCE { -- KDF2-Parms 713 id-sha1 -- no parameters (preferred) 714 } 715 }, 716 [2] SEQUENCE { -- other information method 717 id-specifiedOtherInfo, -- specified other info. 718 ''H -- empty string 719 } 720 } 721 }, 722 [1] SEQUENCE { -- symmetric key wrapping scheme 723 id-aes128-Wrap -- AES-128 Wrap; no parameters 724 }, 725 [2] SEQUENCE { -- label method 726 id-specifiedLabel, -- specified label 727 ''H -- empty string 728 } 729 } 730 } 732 Full Copyright Statement 734 Copyright (C) The Internet Society (2003). All Rights Reserved. 736 This document and translations of it may be copied and furnished to 737 others, and derivative works that comment on or otherwise explain it 738 or assist in its implementation may be prepared, copied, published 739 and distributed, in whole or in part, without restriction of any 740 kind, provided that the above copyright notice and this paragraph 741 are included on all such copies and derivative works. However, this 742 document itself may not be modified in any way, such as by removing 743 the copyright notice or references to the Internet Society or other 744 Internet organizations, except as needed for the purpose of 745 developing Internet standards in which case the procedures for 746 copyrights defined in the Internet Standards process must be 747 followed, or as required to translate it into languages other than 748 English. 750 The limited permissions granted above are perpetual and will not be 751 revoked by the Internet Society or its successors or assigns.