idnits 2.17.1 draft-ietf-smime-cms-rsa-kem-01.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 document is more than 15 pages and seems to lack a Table of Contents. == There are 5 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 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 document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (October 2003) is 7498 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 50 looks like a reference -- Missing reference section? 'PKCS1' on line 738 looks like a reference -- Missing reference section? 'ISO-IEC-18033-2' on line 698 looks like a reference -- Missing reference section? 'NESSIE' on line 100 looks like a reference -- Missing reference section? 'SHOUP' on line 236 looks like a reference -- Missing reference section? 'CMS' on line 117 looks like a reference -- Missing reference section? 'CMSALGS' on line 123 looks like a reference -- Missing reference section? 'CMS-OAEP' on line 125 looks like a reference -- Missing reference section? 'FIPS-180-2' on line 143 looks like a reference -- Missing reference section? 'AES-WRAP' on line 756 looks like a reference -- Missing reference section? '3DES-WRAP' on line 768 looks like a reference -- Missing reference section? 'PROFILE' on line 196 looks like a reference -- Missing reference section? 'MSG' on line 210 looks like a reference -- Missing reference section? 'NIST-GUIDELINE' on line 274 looks like a reference -- Missing reference section? 'RANDOM' on line 279 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 17 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-01.txt October 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-forward) 37 mechanism for transporting keying data to a recipient using the 38 recipient's RSA public key. This document specifies the conventions 39 for using the RSA-KEM Key Transport Algorithm with the Cryptographic 40 Message Syntax (CMS). This version (-01) updates the ASN.1 syntax to 41 align with the latest drafts of ANS X9.44 and ISO/IEC 18033-2, and 42 adds material on certificate conventions and S/MIME capabilities. 44 Conventions Used in This Document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in RFC 2119 49 [STDWORDS]. 51 1. Introduction 53 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 54 mechanism for transporting keying data to a recipient using the 55 recipient's RSA public key. 57 Most previous key transport algorithms based on the RSA public-key 58 cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have 59 the following general form: 61 1. Format or "pad" the keying data to obtain an integer m. 63 2. Encrypt the integer m with the recipient's RSA public key: 65 c = m^e mod n 67 3. Output c as the encrypted keying data. 69 The RSA-KEM Key Transport Algorithm takes a different approach that 70 provides higher security assurance, by encrypting a _random_ integer 71 with the recipient's public key, and using a symmetric key-wrapping 72 scheme to encrypt the keying data. It has the following form: 74 1. Generate a random integer z between 0 and n-1. 76 2. Encrypt the integer z with the recipient's RSA public key: 78 c = z^e mod n. 80 3. Derive a key-encrypting key KEK from the integer z. 82 4. Wrap the keying data using KEK to obtain wrapped keying data 83 WK. 85 5. Output c and WK as the encrypted keying data. 87 This different approach provides higher security assurance because 88 the input to the underlying RSA operation is random and independent 89 of the message, and the key-encrypting key KEK is derived from it in 90 a strong way. As a result, the algorithm enjoys a "tight" security 91 proof in the random oracle model. It is also architecturally 92 convenient because the public-key operations are separate from the 93 symmetric operations on the keying data. One benefit is that the 94 length of the keying data is bounded only by the symmetric key- 95 wrapping scheme, not the size of the RSA modulus. 97 The RSA-KEM Key Transport Algorithm in various forms is being adopted 98 in several draft standards including the draft ANS X9.44 [ANS-X9.44] 99 and the draft ISO/IEC 18033-2 [ISO-IEC-18033-2]. It has also been 100 recommended by the NESSIE project [NESSIE]. Although the other 101 standards are still in development, the algorithm is stable across 102 the drafts. For completeness, a specification of the algorithm is 103 given in Appendix A of this document; ASN.1 syntax is given in 104 Appendix B. 106 NOTE: The term KEM stands for "key encapsulation mechanism" and 107 refers to the first three steps of the process above. The 108 formalization of key transport algorithms (or more generally, 109 asymmetric encryption schemes) in terms of key encapsulation 110 mechanisms is described further in research by Victor Shoup leading 111 to the development of the ISO/IEC 18033-2 standard [SHOUP]. 113 2. Use in CMS 115 The RSA-KEM Key Transport Algorithm MAY be employed for one or more 116 recipients in the CMS enveloped-data content type (Section 6 of 117 [CMS]), where the keying data processed by the algorithm is the CMS 118 content-encryption key. 120 The RSA-KEM Key Transport Algorithm SHOULD be considered for new 121 CMS-based applications as a replacement for the widely implemented 122 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see 123 [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to 124 chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm 125 has also been proposed as a replacement (see [PKCS1] and [CMS- 126 OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter 127 security proof, but the disadvantage of slightly longer encrypted 128 keying data. 130 2.1 Underlying Components 132 A CMS implementation that supports the RSA-KEM Key Transport 133 Algorithm MUST support at least the following underlying components: 135 * For the key derivation function, KDF2 (see [ANS-X9.44][IEEE- 136 P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function is 137 also specified as the key derivation function in [ANS-X9.63]) 139 * For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key 140 Wrap with a 128-bit key encrypting key (see [AES-WRAP]) 142 An implementation SHOULD also support KDF2 based on SHA-256 (see 143 [FIPS-180-2]), and the Triple-DES Key Wrap (see [3DES-WRAP]). It MAY 144 support other underlying components. 146 2.2 RecipientInfo Conventions 148 When the RSA-KEM Key Transport Algorithm is employed for a recipient, 149 recipient, the RecipientInfo alternative for that recipient MUST be 150 KeyTransRecipientInfo. The algorithm-specific fields of the 151 KeyTransRecipientInfo value MUST have the following values: 153 * keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid 154 (see Appendix B) 156 * keyEncryptionAlgorithm.parameters MUST be a value of type 157 GenericHybridParameters, identifying the RSA-KEM key 158 encapsulation mechanism (see Appendix B) 160 * encryptedKey MUST be the encrypted keying data output by the 161 algorithm (see Appendix A) 163 2.3 Certificate Conventions 165 The conventions specified in this section augment RFC 3280 [PROFILE]. 167 A recipient who employs the RSA-KEM Key Transport Algorithm MAY 168 identify the public key in a certificate by the same 169 AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using 170 the rsaEncryption object identifier [PKCS1]. 172 If the recipient wishes only to employ the RSA-KEM Key Transport 173 Algorithm with a given public key, the recipient MUST identify the 174 public key in the certificate using the id-ac-generic-hybrid object 175 identifier (see Appendix B) where the associated 176 GenericHybridParameters value indicates the underlying components 177 with which the algorithm is to be employed. The certificate user MUST 178 perform the RSA-KEM Key Transport algorithm using only those 179 components. 181 Regardless of the AlgorithmIdentifier used, the RSA public key is 182 encoded in the same manner in the subject public key information. 183 The RSA public key MUST be encoded using the type RSAPublicKey type: 185 RSAPublicKey ::= SEQUENCE { 186 modulus INTEGER, -- n 187 publicExponent INTEGER -- e 188 } 190 Here, the modulus is the modulus n, and publicExponent is the public 191 exponent e. The DER encoded RSAPublicKey is carried in the 192 subjectPublicKey BIT STRING within the subject public key 193 information. 195 The intended application for the key MAY be indicated in the key 196 usage certificate extension (see [PROFILE], Section 4.2.1.3). If the 197 keyUsage extension is present in a certificate that conveys an RSA 198 public key with the id-ac-generic-hybrid object identifier as 199 discussed above, then the key usage extension MUST contain the 200 following value: 202 keyEncipherment. 204 dataEncipherment SHOULD NOT be present. That is, a key intended to be 205 employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT 206 also be employed for data encryption. 208 2.4 SMIMECapabilities Attribute Conventions 210 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 211 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 212 used to specify a partial list of algorithms that the software 213 announcing the SMIMECapabilities can support. When constructing a 214 signedData object, compliant software MAY include the 215 SMIMECapabilities signed attribute announcing that it supports the 216 RSA-KEM Key Transport algorithm. 218 The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport 219 Algorithm MUST include the id-ac-generic-hybrid object identifier 220 (see Appendix B) in the capabilityID field and MUST include a 221 GenericHybridParameters value in the parameters field identifying the 222 components with which the algorithm is to be employed. 224 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 225 encoding of an AlgorithmIdentifier. Example DER encodings for typical 226 sets of components are given in Appendix B.4. 228 3. Security Considerations 230 The security of the RSA-KEM Key Transport Algorithm described in 231 this document can be shown to be tightly related to the difficulty 232 of either solving the RSA problem or breaking the underlying 233 symmetric key-wrapping scheme, if the underlying key derivation 234 function is modeled as a random oracle, and assuming that the 235 symmetric key-wrapping scheme satisfies the properties of a data 236 encapsulation mechanism [SHOUP]. While in practice a random-oracle 237 result does not provide an actual security proof for any particular 238 key derivation function, the result does provide assurance that the 239 general construction is reasonable; a key derivation function would 240 need to be particularly weak to lead to an attack that is not 241 possible in the random oracle model. 243 The RSA key size and the underlying components should be selected 244 consistent with the desired symmetric security level for an 245 application. Several security levels have been identified in [NIST- 246 GUIDELINE]. For brevity, the first three levels are mentioned here: 248 * 80-bit security. The RSA key size SHOULD be at least 1024 bits, 249 the hash function underlying KDF2 SHOULD be SHA-1 or above, and 250 the symmetric key-wrapping scheme SHOULD be AES Key Wrap or 251 Triple-DES Key Wrap. 253 * 112-bit security. The RSA key size SHOULD be at least 2048 254 bits, the hash function underlying KDF2 SHOULD be SHA-224 or 255 above, and the symmetric key-wrapping scheme SHOULD be AES Key 256 Wrap or Triple-DES Key Wrap. 258 * 128-bit security. The RSA key size SHOULD be at least 3072 259 bits, the hash function underlying KDF2 SHOULD be SHA-256 or 260 above, and the symmetric key-wrapping scheme SHOULD be AES Key 261 Wrap. 263 Note that the AES Key Wrap MAY be used at all three of these levels; 264 the use of AES does not require a 128-bit security level for other 265 components. 267 Implementations MUST protect the RSA private key and the content- 268 encryption key. Compromise of the RSA private key may result in the 269 disclosure of all messages protected with that key. Compromise of the 270 content-encryption key may result in disclosure of the associated 271 encrypted content. 273 Additional considerations related to key management may be found in 274 [NIST-GUIDELINE]. 276 The security of the algorithm also depends on the strength of the 277 random number generator, which SHOULD have a comparable security 278 level. For further discussion on random number generation, please 279 see [RANDOM]. 281 Implementations SHOULD NOT reveal information about intermediate 282 values or calculations, whether by timing or other "side channels", 283 or otherwise an opponent may be able to determine information about 284 the keying data and/or the recipient's private key. Although not all 285 intermediate information may be useful to an opponent, it is 286 preferable to conceal as much information as is practical, unless 287 analysis specifically indicates that the information would not be 288 useful. 290 Generally, good cryptographic practice employs a given RSA key pair 291 in only one scheme. This practice avoids the risk that vulnerability 292 in one scheme may compromise the security of the other, and may be 293 essential to maintain provable security. While RSA public keys have 294 often been employed for multiple purposes such as key transport and 295 digital signature without any known bad interactions, for increased 296 security assurance, such combined use of an RSA key pair is NOT 297 RECOMMENDED in the future (unless the different schemes are 298 specifically designed to be used together). 300 Accordingly, an RSA key pair used for the RSA-KEM Key Transport 301 Algorithm SHOULD NOT also be used for digital signatures. (Indeed, 302 ASC X9 requires such a separation between key establishment key pairs 303 and digital signature key pairs.) Continuing this principle of key 304 separation, a key pair used for the RSA-KEM Key Transport Algorithm 305 SHOULD NOT be used with other key establishment schemes, or for data 306 encryption, or with more than one set of underlying algorithm 307 components. 309 Parties MAY wish to formalize the assurance that one another's 310 implementations are correct through implementation validation, e.g. 311 NIST's Cryptographic Module Validation Program (CMVP). 313 4. References 315 4.1 Normative References 317 3DES-WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC 318 3217. December 2001. 320 AES-WRAP Schaad, J. and R. Housley. Advanced Encryption 321 Standard (AES) Key Wrap Algorithm. RFC 3394. 322 September 2002. 324 ANS-X9.63 American National Standard X9.63-2002: Public Key 325 Cryptography for the Financial Services Industry: 326 Key Agreement and Key Transport Using Elliptic 327 Curve Cryptography. 329 CMS Housley, R. Cryptographic Message Syntax. RFC 330 3369. August 2002. 332 CMSALGS Housley, R. Cryptographic Message Syntax (CMS) 333 Algorithms. RFC 3370. August 2002. 335 FIPS-180-2 National Institute of Standards and Technology 336 (NIST). FIPS 180-2: Secure Hash Standard. August 337 2002. 339 MSG Ramsdell, B. S/MIME Version 3 Message 340 Specification. RFC 2633. June 1999. 342 PROFILE Housley, R., Polk, W., Ford, W. and D. Solo. 343 Internet X.509 Public Key Infrastructure: 344 Certificate and Certificate Revocation List (CRL) 345 Profile. RFC 3280. April 2002. 347 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 348 Requirement Levels. RFC 2119. March 1997. 350 4.2 Informative References 352 ANS-X9.44 ASC X9F1 Working Group. Draft American National 353 Standard X9.44: Public Key Cryptography for the 354 Financial Services Industry -- Key Establishment 355 Using Integer Factorization Cryptography. Draft D6, 356 October 15, 2003. 358 CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport 359 Algorithm in the Cryptographic Message Syntax 360 (CMS). RFC 3560. July 2003. 362 IEEE-P1363a IEEE P1363 Working Group. IEEE P1363a: Standard 363 Specifications for Public Key Cryptography: 364 Additional Techniques. Draft D12, May 12, 2003. 365 Available via http://grouper.ieee.org/groups/1363. 367 ISO-IEC-18033-2 ISO/IEC 18033-2: Information technology -- Security 368 techniques -- Encryption algorithms � Part 2: 369 Asymmetric Ciphers. 2nd Committee Draft, July 10, 370 2003. 372 NESSIE NESSIE Consortium. Portfolio of Recommended 373 Cryptographic Primitives. February 27, 2003. 374 Available via http://www.cryptonessie.org/. 376 NIST-GUIDELINE National Institute of Standards and Technology. 377 Special Publication 800-57: Recommendation for Key 378 Management. Part 1: General Guideline. Draft, 379 January 2003. Available via 380 http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. 382 PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA 383 Cryptography Specifications Version 2.1. RFC 3447. 384 February 2003. 386 RANDOM Eastlake, D., S. Crocker, and J. Schiller. 387 Randomness Recommendations for Security. RFC 1750. 388 December 1994. 390 SHOUP Shoup, V. A Proposal for an ISO Standard for 391 Public Key Encryption. Version 2.1, December 20, 392 2001. Available via http://www.shoup.net/papers/. 394 5. IANA Considerations 396 Within the CMS, algorithms are identified by object identifiers 397 (OIDs). With one exception, all of the OIDs used in this document 398 were assigned in other IETF documents, in ISO/IEC standards 399 documents, by the National Institute of Standards and Technology 400 (NIST), and in Public-Key Cryptography Standards (PKCS) documents. 401 The one exception is that the ASN.1 module's identifier (see Appendix 402 B.3) is assigned in this document. No further action by the IANA is 403 necessary for this document or any anticipated updates. 405 6. Acknowledgments 407 This document is one part of a strategy to align algorithm standards 408 produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. I would 409 like to thank the members of the ASC X9F1 working group for their 410 contributions to drafts of ANS X9.44 which led to this specification. 411 My thanks as well to Russ Housley as well for his guidance and 412 encouragement. I also appreciate the helpful direction I've received 413 from Blake Ramsdell and Jim Schaad in bringing this document to 414 fruition. 416 7. Author's Address 418 Burt Kaliski 419 RSA Laboratories 420 174 Middlesex Turnpike 421 Bedford, MA 01730 422 USA 423 bkaliski@rsasecurity.com 425 Appendix A. RSA-KEM Key Transport Algorithm 427 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 428 mechanism for transporting keying data to a recipient using the 429 recipient's RSA public key. 431 With this type of algorithm, a sender encrypts the keying data using 432 the recipient's public key to obtain encrypted keying data. The 433 recipient decrypts the encrypted keying data using the recipient's 434 private key to recover the keying data. 436 A.1 Underlying Components 438 The algorithm has the following underlying components: 440 * KDF, a key derivation function, which derives keying data of a 441 specified length from a shared secret value 443 * Wrap, a symmetric key-wrapping scheme, which encrypts keying 444 data using a key-encrypting key 446 In the following, kekLen denotes the length in bytes of the key- 447 encrypting key for the underlying symmetric key-wrapping scheme. 449 In this scheme, the length of the keying data to be transported MUST 450 be among the lengths supported by the underlying symmetric key- 451 wrapping scheme. (The AES Key Wrap, for instance, requires the length 452 of the keying data to be a multiple of 8 bytes, and at least 16 453 bytes.) Usage and formatting of the keying data (e.g., parity 454 adjustment for Triple-DES keys) is outside the scope of this 455 algorithm. 457 With some key derivation functions, it is possible to include other 458 information besides the shared secret value in the input to the 459 function. Also, with some symmetric key-wrapping schemes, it is 460 possible to associate a label with the keying data. Such uses are 461 outside the scope of this document, as they are not directly 462 supported by CMS. 464 A.2 Sender's Operations 466 Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) 467 and let K be the keying data to be transported. 469 Let nLen denote the length in bytes of the modulus n, i.e., the least 470 integer such that 2^{8*nLen} > n. 472 The sender performs the following operations: 474 1. Generate a random integer z between 0 and n-1 (see Note), and 475 convert z to a byte string Z of length nLen, most significant 476 byte first: 478 z = RandomInteger (0, n-1) 479 Z = IntegerToString (z, nLen) 481 2. Encrypt the random integer z using the recipient's public key 482 (n,e) and convert the resulting integer c to a ciphertext C, a 483 byte string of length nLen: 485 c = z^e mod n 486 C = IntegerToString (c, nLen) 488 3. Derive a key-encrypting key KEK of length kekLen bytes from the 489 byte string Z using the underlying key derivation function: 491 KEK = KDF (Z, kekLen) 493 4. Wrap the keying data K with the key-encrypting key KEK using 494 the underlying key-wrapping scheme to obtain wrapped keying 495 data WK: 497 WK = Wrap (KEK, K) 499 5. Concatenate the ciphertext C and the wrapped keying data WK to 500 obtain the encrypted keying data EK: 502 EK = C || WK 504 6. Output the encrypted keying data EK. 506 NOTE: The random integer z MUST be generated independently at random 507 for different encryption operations, whether for the same or 508 different recipients. 510 A.3 Recipient's Operations 512 Let (n,d) be the recipient's RSA private key (see [PKCS1]; other 513 private key formats are allowed) and let EK be the encrypted keying 514 data. 516 Let nLen denote the length in bytes of the modulus n. 518 The recipient performs the following operations: 520 1. Separate the encrypted keying data EK into a ciphertext C of 521 length nLen bytes and wrapped keying data WK: 523 C || WK = EK 525 If the length of the encrypted keying data is less than nLen 526 bytes, output "decryption error" and stop. 528 2. Convert the ciphertext C to an integer c, most significant 529 byte first. Decrypt the integer c using the recipient's 530 private key (n,d) to recover an integer z (see Note): 532 c = StringToInteger (C) 533 z = c^d mod n 535 If the integer c is not between 0 and n-1, output "decryption 536 error" and stop. 538 3. Convert the integer z to a byte string Z of length nLen, most 539 significant byte first (see Note): 541 Z = IntegerToString (z, nLen) 543 4. Derive a key-encrypting key KEK of length kekLen bytes from 544 the byte string Z using the underlying key derivation function 545 (see Note): 547 KEK = KDF (Z, kekLen) 549 5. Unwrap the wrapped keying data WK with the key-encrypting key 550 KEK using the underlying key-wrapping scheme to recover the 551 keying data K: 553 K = Unwrap (KEK, WK) 555 If the unwrapping operation outputs an error, output 556 "decryption error" and stop. 558 6. Output the keying data K. 560 NOTE: Implementations SHOULD NOT reveal information about the integer 561 z and the string Z, nor about the calculation of the exponentiation 562 in Step 2, the conversion in Step 3, or the key derivation in Step 4, 563 whether by timing or other "side channels". The observable behavior 564 of the implementation SHOULD be the same at these steps for all 565 ciphertexts C that are in range. (For example, IntegerToString 566 conversion should take the same amount of time regardless of the 567 actual value of the integer z.) The integer z, the string Z and other 568 intermediate results MUST be securely deleted when they are no longer 569 needed. 571 Appendix B. ASN.1 Syntax 573 The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm 574 is an extension of the syntax for the "generic hybrid cipher" in the 575 draft ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed 576 in the draft ANS X9.44 [ANS-X9.44]. The syntax for the scheme is 577 given in Section B.1. The syntax for selected underlying components 578 including those mentioned above is given in B.2. 580 The following object identifier prefixes are used in the definitions 581 below: 583 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 585 nistAlgorithm OID ::= { 586 joint-iso-itu-t(2) country(16) us(840) organization(1) 587 gov(101) csor(3) nistAlgorithm(4) 588 } 590 pkcs-1 OID ::= { 591 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 592 } 594 NullParms is a more descriptive synonym for NULL when an algorithm 595 identifier has null parameters: 597 NullParms ::= NULL 599 The material in this Appendix is based on a draft standard and is 600 SUBJECT TO CHANGE as that standard is developed. 602 B.1 RSA-KEM Key Transport Algorithm 604 The object identifier for the RSA-KEM Key Transport Algorithm is the 605 same as for the "generic hybrid cipher" in the draft ANS ISO/IEC 606 18033-2, id-ac-generic-hybrid, which is defined in the draft as 608 id-ac-generic-hybrid OID ::= { 609 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 610 } 612 The associated parameters for id-ac-generic-hybrid have type 613 GenericHybridParameters: 615 GenericHybridParameters ::= { 616 kem KeyEncapsulationMechanism, 617 dem DataEncapsulationMechanism 618 } 620 The fields of type GenericHybridParameters have the following 621 meanings: 623 * kem identifies the underlying key encapsulation mechanism. For 624 the RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from 625 the draft ISO/IEC 18033-2. 627 The object identifier for RSA-KEM (as a key encapsulation 628 mechanism) is id-kem-rsa, which is defined in the draft ISO/IEC 629 18033-2 as 631 id-kem-rsa OID ::= { 632 is18033-2 key-encapsulation-mechanism(2) rsa(4) 633 } 635 The associated parameters for id-kem-rsa have type 636 RsaKemParameters: 638 RsaKemParameters ::= { 639 keyDerivationFunction KeyDerivationFunction, 640 keyLength KeyLength 641 } 643 The fields of type RsaKemParameters have the following 644 meanings: 646 * keyDerivationFunction identifies the underlying key 647 derivation function. For alignment with the draft ANS 648 X9.44, it MUST be KDF2. However, other key derivation 649 functions MAY be used with CMS. Please see B.2.1 for the 650 syntax for KDF2. 652 KeyDerivationFunction ::= 653 AlgorithmIdentifier {{KDFAlgorithms}} 655 KDFAlgorithms ALGORITHMS ::= { 656 kdf2, 657 ... -- implementations may define other methods 658 } 660 * keyLength is the length in bytes of the key-encrypting 661 key, which depends on the underlying symmetric key- 662 wrapping scheme. 664 KeyLength ::= INTEGER (1..MAX) 666 * dem identifies the underlying data encapsulation mechanism. 667 For alignment with the draft ANS X9.44, it MUST be an X9- 668 approved symmetric key-wrapping scheme. (See Note.) However, 669 other symmetric key-wrapping schemes MAY be used with CMS. 670 Please see B.2.2 for the syntax for the AES and Triple-DES Key 671 Wraps. 673 DataEncapsulationMechanism ::= 674 AlgorithmIdentifier {{DEMAlgorithms}} 676 DEMAlgorithms ALGORITHM ::= { 677 X9-SymmetricKeyWrappingSchemes, 678 ... -- implementations may define other methods 679 } 680 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 681 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 682 ... -- allows for future expansion 683 } 685 NOTE: The generic hybrid cipher in the draft ISO/IEC 18033-2 can 686 encrypt arbitrary data, hence the term "data encapsulation 687 mechanism". The symmetric key-wrapping schemes take the role of data 688 encapsulation mechanisms in the RSA-KEM Key Transport Algorithm. The 689 draft ISO/IEC 18033-2 currently allows only three particular data 690 encapsulation mechanisms, not including any of these symmetric key- 691 wrapping schemes. However, the ASN.1 syntax in that document expects 692 that additional algorithms will be allowed. 694 B.2 Selected Underlying Components 696 B.2.1 Key Derivation Functions 698 The object identifier for KDF2 (see [ISO-IEC-18033-2]) is 700 id-kdf-kdf2 OID ::= { 701 is18033-2 key-derivation-functions(5) kdf2(2) 702 } 704 The associated parameters identify the underlying hash function. For 705 alignment with the draft ANS X9.44, the hash function MUST be an ASC 706 X9-approved hash function. (See Note.) However, other hash functions 707 MAY be used with CMS. 709 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 711 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 713 KDF2-HashFunctions ALGORITHM ::= { 714 X9-HashFunctions, 715 ... -- implementations may define other methods 716 } 718 X9-HashFunctions ALGORITHM ::= { 719 sha1 | sha224 | sha256 | sha384 | sha512, 720 ... -- allows for future expansion 721 } 723 The object identifier for SHA-1 is 725 id-sha1 OID ::= { 726 iso(1) identified-organization(3) oiw(14) secsig(3) 727 algorithms(2) sha1(26) 728 } 730 The object identifiers for SHA-256, SHA-384 and SHA-512 are 732 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 733 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 734 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 736 There has been some confusion over whether the various SHA object 737 identifiers have a NULL parameter, or no associated parameters. As 738 also discussed in [PKCS1], implementations SHOULD generate algorithm 739 identifiers without parameters, and MUST accept algorithm identifiers 740 either without parameters, or with NULL parameters. 742 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be 743 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 744 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 745 sha384 ALGORITHM ::= {{ OID id-sha384 }} �- "" 746 sha512 ALGORITHM ::= {{ OID id-sha512 }} �- "" 748 NOTE: As of this writing, only SHA-1 is an ASC X9-approved hash 749 function; SHA-224 and above are in the process of being approved. The 750 object identifier for SHA-224 has not yet been assigned. 752 B.2.2 Symmetric Key-Wrapping Schemes 754 The object identifiers for the AES Key Wrap depends on the size of 755 the key encrypting key. There are three object identifiers (see 756 [AES-WRAP]): 758 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 759 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 760 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 762 These object identifiers have no associated parameters. 764 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 765 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 766 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 768 The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) 769 is 771 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 772 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 773 smime(16) alg(3) 6 774 } 776 This object identifier has a NULL parameter. 778 tdes-Wrap ALGORITHM ::= 779 {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 781 NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key 782 Wrap are in the process of being approved by ASC X9. 784 B.3 ASN.1 module 786 CMS-RSA-KEM 787 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 788 pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } [[check]] 790 BEGIN 792 -- EXPORTS ALL 794 -- IMPORTS None 796 -- Useful types and definitions 798 OID ::= OBJECT IDENTIFIER -- alias 800 -- Unless otherwise stated, if an object identifier has associated 801 -- parameters (i.e., the PARMS element is specified), the parameters 802 -- field shall be included in algorithm identifier values. The 803 -- parameters field shall be omitted if and only if the object 804 -- identifier does not have associated parameters (i.e., the PARMS 805 -- element is omitted), unless otherwise stated. 807 ALGORITHM ::= CLASS { 808 &id OBJECT IDENTIFIER UNIQUE, 809 &Type OPTIONAL 810 } 811 WITH SYNTAX { OID &id [PARMS &Type] } 813 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 814 algorithm ALGORITHM.&id( {IOSet} ), 815 parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL 816 } 818 NullParms ::= NULL 820 -- ISO/IEC 18033-2 arc 822 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 824 -- NIST algorithm arc 826 nistAlgorithm OID ::= { 827 joint-iso-itu-t(2) country(16) us(840) organization(1) 828 gov(101) csor(3) nistAlgorithm(4) 829 } 831 -- PKCS #1 arc 833 pkcs-1 OID ::= { 834 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 835 } 836 -- RSA-KEM Key Transport Algorithm, based on Generic Hybrid Cipher 838 id-ac-generic-hybrid OID ::= { 839 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 840 } 842 GenericHybridParameters ::= { 843 kem KeyEncapsulationMechanism, 844 dem DataEncapsulationMechanism 845 } 847 id-kem-rsa OID ::= { 848 is18033-2 key-encapsulation-mechanism(2) rsa(4) 849 } 851 RsaKemParameters ::= { 852 keyDerivationFunction KeyDerivationFunction, 853 keyLength KeyLength 854 } 856 KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} 858 KDFAlgorithms ALGORITHMS ::= { 859 kdf2, 860 ... -- implementations may define other methods 861 } 863 KeyLength ::= INTEGER (1..MAX) 865 DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} 867 DEMAlgorithms ALGORITHM ::= { 868 X9-SymmetricKeyWrappingSchemes, 869 ... -- implementations may define other methods 870 } 872 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 873 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 874 ... -- allows for future expansion 875 } 877 -- Key Derivation Functions 879 id-kdf-kdf2 OID ::= { is18033-2 key-derivation-functions(5) kdf2(2) } 881 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 883 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 885 KDF2-HashFunctions ALGORITHM ::= { 886 X9-HashFunctions, 887 ... -- implementations may define other methods 888 } 889 -- Hash Functions 891 X9-HashFunctions ALGORITHM ::= { 892 sha1 | sha224 | sha256 | sha384 | sha512, 893 ... -- allows for future expansion 894 } 896 id-sha1 OID ::= { 897 iso(1) identified-organization(3) oiw(14) secsig(3) 898 algorithms(2) sha1(26) 899 } 901 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 902 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 903 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 905 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NullParms MUST be 906 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 907 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 908 sha384 ALGORITHM ::= {{ OID id-sha384 }} �- "" 909 sha512 ALGORITHM ::= {{ OID id-sha512 }} �- "" 911 -- Symmetric Key-Wrapping Schemes 913 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 914 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 915 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 917 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 918 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 919 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 921 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 922 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 923 smime(16) alg(3) 6 924 } 926 tdes-Wrap ALGORITHM ::= {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 928 B.4 Examples 930 As an example, if the key derivation function is KDF2 based on 931 SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap 932 with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key 933 Transport Algorithm will have the following value: 935 SEQUENCE { 936 id-ac-generic-hybrid, -- generic cipher 937 SEQUENCE { -- GenericHybridParameters 938 SEQUENCE { -- key encapsulation mechanism 939 id-kem-rsa, -- RSA-KEM 940 SEQUENCE { -- RsaKemParameters 941 SEQUENCE { -- key derivation function 942 id-kdf-kdf2, -- KDF2 943 SEQUENCE { -- KDF2-HashFunction 944 id-sha256 -- SHA-256; no parameters (preferred) 945 }, 946 16 -- KEK length in bytes 947 }, 948 SEQUENCE { -- data encapsulation mechanism 949 id-aes128-Wrap -- AES-128 Wrap; no parameters 950 } 951 } 952 } 954 This AlgorithmIdentifier value has the following DER encoding: 956 30 4f 957 06 07 28 81 8c 71 02 01 02 -- id-ac-generic-hybrid 958 30 44 959 30 25 960 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 961 30 1a 962 30 16 963 06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 964 30 0b 965 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 966 02 10 -- 16 bytes 967 30 0b 968 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 970 The DER encodings for other typical sets of underlying components are 971 as follows: 973 * KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK 975 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 976 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 977 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 978 02 02 02 18 30 0b 06 09 60 86 48 01 65 03 04 01 979 19 981 * KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK 983 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 984 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 985 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 986 02 03 02 20 30 0b 06 09 60 86 48 01 65 03 04 01 987 2d 989 * KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK 990 (two-key triple-DES) 992 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 993 07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81 994 8c 71 02 05 02 30 07 06 05 2b 0e 03 02 1a 02 10 995 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 996 00 998 * KDF2 based on SHA-224, Triple-DES Key Wrap with a 192-bit 999 KEK (three-key triple-DES) 1001 [[to be defined, awaiting OID for SHA-224]] 1003 Full Copyright Statement 1005 Copyright (C) The Internet Society (2003). All Rights Reserved. 1007 This document and translations of it may be copied and furnished to 1008 others, and derivative works that comment on or otherwise explain it 1009 or assist in its implementation may be prepared, copied, published 1010 and distributed, in whole or in part, without restriction of any 1011 kind, provided that the above copyright notice and this paragraph 1012 are included on all such copies and derivative works. However, this 1013 document itself may not be modified in any way, such as by removing 1014 the copyright notice or references to the Internet Society or other 1015 Internet organizations, except as needed for the purpose of 1016 developing Internet standards in which case the procedures for 1017 copyrights defined in the Internet Standards process must be 1018 followed, or as required to translate it into languages other than 1019 English. 1021 The limited permissions granted above are perpetual and will not be 1022 revoked by the Internet Society or its successors or assigns.