idnits 2.17.1 draft-ietf-smime-cms-rsa-kem-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 34. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1107), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1107. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 (March 2006) is 6617 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 68 looks like a reference -- Missing reference section? 'PKCS1' on line 765 looks like a reference -- Missing reference section? 'NESSIE' on line 118 looks like a reference -- Missing reference section? 'SHOUP' on line 262 looks like a reference -- Missing reference section? 'CMS' on line 134 looks like a reference -- Missing reference section? 'CMSALGS' on line 140 looks like a reference -- Missing reference section? 'CMS-OAEP' on line 142 looks like a reference -- Missing reference section? 'IEEE-P1363a' on line 153 looks like a reference -- Missing reference section? 'FIPS-180-2' on line 160 looks like a reference -- Missing reference section? 'AES-WRAP' on line 799 looks like a reference -- Missing reference section? '3DES-WRAP' on line 811 looks like a reference -- Missing reference section? 'Camillia' on line 161 looks like a reference -- Missing reference section? 'PROFILE' on line 218 looks like a reference -- Missing reference section? 'MSG' on line 236 looks like a reference -- Missing reference section? 'NIST-GUIDELINE' on line 301 looks like a reference -- Missing reference section? 'RANDOM' on line 306 looks like a reference -- Missing reference section? 'ISO-IEC-18033-2' on line 728 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group B.Kaliski/J.Randall 3 Internet Draft RSA Laboratories 4 Document: draft-ietf-smime-cms-rsa-kem-02.txt March 2006 5 Category: Standards 7 Use of the RSA-KEM Key Transport Algorithm in CMS 8 10 Status of this Memo 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Copyright (C) The Internet Society (2006). 24 This document is subject to the rights, licenses and restrictions 25 contained in BCP 78, and except as set forth therein, the authors 26 retain all their rights. 28 This document and the information contained herein are provided on an 29 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 30 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 31 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 32 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 33 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 34 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 36 Internet-Drafts are working documents of the Internet Engineering Task 37 Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference material 42 or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at: 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at: 48 http://www.ietf.org/shadow.html 49 Comments or suggestions for improvement may be made on the "ietf- 50 smime" mailing list, or directly to the author. 52 Abstract 54 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 55 mechanism for transporting keying data to a recipient using the 56 recipient's RSA public key. This document specifies the conventions 57 for using the RSA-KEM Key Transport Algorithm with the Cryptographic 58 Message Syntax (CMS). This version (-02) updates the ASN.1 syntax to 59 align with the latest draft of ANS X9.44 and ISO/IEC 18033-2, and 60 adds material on Camillia algorirthm. 62 Conventions Used in This Document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in RFC 2119 67 [STDWORDS]. 69 1. Introduction 71 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 72 mechanism for transporting keying data to a recipient using the 73 recipient's RSA public key. 75 Most previous key transport algorithms based on the RSA public-key 76 cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have 77 the following general form: 79 1. Format or "pad" the keying data to obtain an integer m. 81 2. Encrypt the integer m with the recipient's RSA public key: 83 c = m^e mod n 85 3. Output c as the encrypted keying data. 87 The RSA-KEM Key Transport Algorithm takes a different approach that 88 provides higher security assurance, by encrypting a _random_ integer 89 with the recipient's public key, and using a symmetric key-wrapping 90 scheme to encrypt the keying data. It has the following form: 92 1. Generate a random integer z between 0 and n-1. 94 2. Encrypt the integer z with the recipient's RSA public key: 96 c = z^e mod n. 98 3. Derive a key-encrypting key KEK from the integer z. 100 4. Wrap the keying data using KEK to obtain wrapped keying data 101 WK. 103 5. Output c and WK as the encrypted keying data. 105 This different approach provides higher security assurance because 106 the input to the underlying RSA operation is random and independent 107 of the message, and the key-encrypting key KEK is derived from it in 108 a strong way. As a result, the algorithm enjoys a "tight" security 109 proof in the random oracle model. It is also architecturally 110 convenient because the public-key operations are separate from the 111 symmetric operations on the keying data. One benefit is that the 112 length of the keying data is bounded only by the symmetric key- 113 wrapping scheme, not the size of the RSA modulus. 115 The RSA-KEM Key Transport Algorithm in various forms is being adopted 116 in several draft standards including the draft ANS X9.44 [ANS-X9.44] 117 and ISO/IEC 18033-2. It has also been recommended by the NESSIE 118 project [NESSIE]. For completeness, a specification of the algorithm 120 is given in Appendix A of this document; ASN.1 syntax is given in 121 Appendix B. 123 NOTE: The term KEM stands for "key encapsulation mechanism" and 124 refers to the first three steps of the process above. The 125 formalization of key transport algorithms (or more generally, 126 asymmetric encryption schemes) in terms of key encapsulation 127 mechanisms is described further in research by Victor Shoup leading 128 to the development of the ISO/IEC 18033-2 standard [SHOUP]. 130 2. Use in CMS 132 The RSA-KEM Key Transport Algorithm MAY be employed for one or more 133 recipients in the CMS enveloped-data content type (Section 6 of 134 [CMS]), where the keying data processed by the algorithm is the CMS 135 content-encryption key. 137 The RSA-KEM Key Transport Algorithm SHOULD be considered for new 138 CMS-based applications as a replacement for the widely implemented 139 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see 140 [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to 141 chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm 142 has also been proposed as a replacement (see [PKCS1] and [CMS- 143 OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter 144 security proof, but the disadvantage of slightly longer encrypted 145 keying data. 147 2.1 Underlying Components 149 A CMS implementation that supports the RSA-KEM Key Transport 150 Algorithm MUST support at least the following underlying components: 152 * For the key derivation function, KDF2 or KDF3 (see [ANS-X9.44] 153 [IEEE-P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function 154 is also specified as the key derivation function in [ANS-X9.63]) 156 * For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key 157 Wrap with a 128-bit key encrypting key (see [AES-WRAP]) 159 An implementation SHOULD also support KDF2 and KDF3 based on SHA-256 160 (see [FIPS-180-2]), the Triple-DES Key Wrap (see [3DES-WRAP]) and the 161 Camillia key wrap algorithm (see [Camillia]). It MAY support other 162 underlying components. When AES or Camilla are used the data block 163 size is 128 bits while the key size can be 128, 192, or 256 bits 164 while Triple DES requires a data block size of 64 bits and a key size 165 of 112 or 168 bits. 167 2.2 RecipientInfo Conventions 169 When the RSA-KEM Key Transport Algorithm is employed for a recipient, 170 the RecipientInfo alternative for that recipient MUST be 171 KeyTransRecipientInfo. The algorithm-specific fields of the 172 KeyTransRecipientInfo value MUST have the following values: 174 * keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid 175 (see Appendix B) 177 * keyEncryptionAlgorithm.parameters MUST be a value of type 178 GenericHybridParameters, identifying the RSA-KEM key 179 encapsulation mechanism (see Appendix B) 181 * encryptedKey MUST be the encrypted keying data output by the 182 algorithm, where the keying data is the content-encryption key. 183 (see Appendix A) 185 2.3 Certificate Conventions 187 The conventions specified in this section augment RFC 3280 [PROFILE]. 189 A recipient who employs the RSA-KEM Key Transport Algorithm MAY 190 identify the public key in a certificate by the same 191 AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using 192 the rsaEncryption object identifier [PKCS1]. 194 If the recipient wishes only to employ the RSA-KEM Key Transport 195 Algorithm with a given public key, the recipient MUST identify the 196 public key in the certificate using the id-ac-generic-hybrid object 197 identifier (see Appendix B) where the associated 198 GenericHybridParameters value indicates the underlying components 199 with which the algorithm is to be employed. The certificate user MUST 200 perform the RSA-KEM Key Transport algorithm using only those 201 components. 203 Regardless of the AlgorithmIdentifier used, the RSA public key is 204 encoded in the same manner in the subject public key information. 205 The RSA public key MUST be encoded using the type RSAPublicKey type: 207 RSAPublicKey ::= SEQUENCE { 208 modulus INTEGER, -- n 209 publicExponent INTEGER -- e 210 } 212 Here, the modulus is the modulus n, and publicExponent is the public 213 exponent e. The DER encoded RSAPublicKey is carried in the 214 subjectPublicKey BIT STRING within the subject public key 215 information. 217 The intended application for the key MAY be indicated in the key 218 usage certificate extension (see [PROFILE], Section 4.2.1.3). If the 219 keyUsage extension is present in a certificate that conveys an RSA 220 public key with the id-ac-generic-hybrid object identifier as 221 discussed above, then the key usage extension MUST contain the 222 following value: 224 keyEncipherment. 226 dataEncipherment SHOULD NOT be present. That is, a key intended to be 227 employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT 228 also be employed for data encryption or for authentication such as in 229 signatures. Good cryptographic practice employs a given RSA key pair 230 in only one scheme. This practice avoids the risk that vulnerability 231 in one scheme may compromise the security of the other, and may be 232 essential to maintain provable security. 234 2.4 SMIMECapabilities Attribute Conventions 236 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 237 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 238 used to specify a partial list of algorithms that the software 239 announcing the SMIMECapabilities can support. When constructing a 240 signedData object, compliant software MAY include the 241 SMIMECapabilities signed attribute announcing that it supports the 242 RSA-KEM Key Transport algorithm. 244 The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport 245 Algorithm MUST include the id-ac-generic-hybrid object identifier 246 (see Appendix B) in the capabilityID field and MUST include a 247 GenericHybridParameters value in the parameters field identifying the 248 components with which the algorithm is to be employed. 250 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 251 encoding of an AlgorithmIdentifier. Example DER encodings for typical 252 sets of components are given in Appendix B.4. 254 3. Security Considerations 256 The security of the RSA-KEM Key Transport Algorithm described in 257 this document can be shown to be tightly related to the difficulty 258 of either solving the RSA problem or breaking the underlying 259 symmetric key-wrapping scheme, if the underlying key derivation 260 function is modeled as a random oracle, and assuming that the 261 symmetric key-wrapping scheme satisfies the properties of a data 262 encapsulation mechanism [SHOUP]. While in practice a random-oracle 263 result does not provide an actual security proof for any particular 264 key derivation function, the result does provide assurance that the 265 general construction is reasonable; a key derivation function would 266 need to be particularly weak to lead to an attack that is not 267 possible in the random oracle model. 269 The RSA key size and the underlying components should be selected 270 consistent with the desired symmetric security level for an 271 application. Several security levels have been identified in [NIST- 272 FIPS PUB 800-57]. For brevity, the first three levels are mentioned 273 here: 275 * 80-bit security. The RSA key size SHOULD be at least 1024 bits, 276 the hash function underlying the KDF SHOULD be SHA-1 or above, 277 and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, 278 Triple-DES Key Wrap, or Camillia Key Wrap. 280 * 112-bit security. The RSA key size SHOULD be at least 2048 281 bits, the hash function underlying the KDF SHOULD be SHA-224 or 282 above, and the symmetric key-wrapping scheme SHOULD be AES Key 283 Wrap, Triple-DES Key Wrap, or Camillia Key Wrap. 285 * 128-bit security. The RSA key size SHOULD be at least 3072 286 bits, the hash function underlying the KDF SHOULD be SHA-256 or 287 above, and the symmetric key-wrapping scheme SHOULD be AES Key 288 Wrap or Camillia Key Wrap. 290 Note that the AES Key Wrap or Camillia Key Wrap MAY be used at all 291 three of these levels; the use of AES or Camillia does not require a 292 128-bit security level for other components. 294 Implementations MUST protect the RSA private key and the content- 295 encryption key. Compromise of the RSA private key may result in the 296 disclosure of all messages protected with that key. Compromise of the 297 content-encryption key may result in disclosure of the associated 298 encrypted content. 300 Additional considerations related to key management may be found in 301 [NIST-GUIDELINE]. 303 The security of the algorithm also depends on the strength of the 304 random number generator, which SHOULD have a comparable security 305 level. For further discussion on random number generation, please 306 see [RANDOM]. 308 Implementations SHOULD NOT reveal information about intermediate 309 values or calculations, whether by timing or other "side channels", 310 or otherwise an opponent may be able to determine information about 311 the keying data and/or the recipient's private key. Although not all 312 intermediate information may be useful to an opponent, it is 313 preferable to conceal as much information as is practical, unless 314 analysis specifically indicates that the information would not be 315 useful. 317 Generally, good cryptographic practice employs a given RSA key pair 318 in only one scheme. This practice avoids the risk that vulnerability 319 in one scheme may compromise the security of the other, and may be 320 essential to maintain provable security. While RSA public keys have 321 often been employed for multiple purposes such as key transport and 322 digital signature without any known bad interactions, for increased 323 security assurance, such combined use of an RSA key pair is NOT 324 RECOMMENDED in the future (unless the different schemes are 325 specifically designed to be used together). 327 Accordingly, an RSA key pair used for the RSA-KEM Key Transport 328 Algorithm SHOULD NOT also be used for digital signatures. (Indeed, 329 ASC X9 requires such a separation between key establishment key pairs 330 and digital signature key pairs.) Continuing this principle of key 331 separation, a key pair used for the RSA-KEM Key Transport Algorithm 332 SHOULD NOT be used with other key establishment schemes, or for data 333 encryption, or with more than one set of underlying algorithm 334 components. 336 Parties MAY formalize the assurance that one another's 337 implementations are correct through implementation validation, e.g. 338 NIST's Cryptographic Module Validation Program (CMVP). 340 4. References 342 4.1 Normative References 344 3DES-WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC 345 3217. December 2001. 347 AES-WRAP Schaad, J. and R. Housley. Advanced Encryption 348 Standard (AES) Key Wrap Algorithm. RFC 3394. 349 September 2002. 351 ANS-X9.63 American National Standard X9.63-2002: Public Key 352 Cryptography for the Financial Services Industry: 353 Key Agreement and Key Transport Using Elliptic 354 Curve Cryptography. 356 CAMILLIA Kato, A., Moriai, S., and Kanda, M.: The Camellia 357 Cipher Algorithm and Its Use With IPsec. RFC 4312. 358 December 2005 360 CMS Housley, R. Cryptographic Message Syntax. RFC 361 3369. August 2002. 363 CMSALGS Housley, R. Cryptographic Message Syntax (CMS) 364 Algorithms. RFC 3370. August 2002. 366 FIPS-180-2 National Institute of Standards and Technology 367 (NIST). FIPS 180-2: Secure Hash Standard. August 368 2002. 370 MSG Ramsdell, B. S/MIME Version 3 Message 371 Specification. RFC 2633. June 1999. 373 PROFILE Housley, R., Polk, W., Ford, W. and D. Solo. 374 Internet X.509 Public Key Infrastructure: 375 Certificate and Certificate Revocation List (CRL) 376 Profile. RFC 3280. April 2002. 378 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 379 Requirement Levels. RFC 2119. March 1997. 381 4.2 Informative References 383 ANS-X9.44 ASC X9F1 Working Group. Draft American National 384 Standard X9.44: Public Key Cryptography for the 385 Financial Services Industry -- Key Establishment 386 Using Integer Factorization Cryptography. Draft 387 D11, January 2006. 389 CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport 390 Algorithm in the Cryptographic Message Syntax 391 (CMS). RFC 3560. July 2003. 393 IEEE-P1363a IEEE Std 1363a-2004: Standard Specifications for 394 Public Key Cryptography: Additional Techniques. 395 IEEE, 2004. 397 ISO-IEC-18033-2 ISO/IEC 18033-2:2005 Information technology -- 398 Security techniques -- Encryption algorithms � 399 Part 2: Asymmetric Ciphers. ISO/IEC, 2005. 401 NESSIE NESSIE Consortium. Portfolio of Recommended 402 Cryptographic Primitives. February 27, 2003. 403 Available via http://www.cryptonessie.org/. 405 NIST-GUIDELINE National Institute of Standards and Technology. 406 Special Publication 800-57: Recommendation for Key 407 Management. Part 1: General Guideline. August 2005. 408 Available via http://csrc.nist.gov/publications/index.html. 410 PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA 411 Cryptography Specifications Version 2.1. RFC 3447. 412 February 2003. 414 RANDOM Eastlake, D., S. Crocker, and J. Schiller. 415 Randomness Recommendations for Security. RFC 1750. 416 December 1994. 418 SHOUP Shoup, V. A Proposal for an ISO Standard for 419 Public Key Encryption. Version 2.1, December 20, 420 2001. Available via http://www.shoup.net/papers/. 422 5. IANA Considerations 424 Within the CMS, algorithms are identified by object identifiers 425 (OIDs). With one exception, all of the OIDs used in this document 426 were assigned in other IETF documents, in ISO/IEC standards 427 documents, by the National Institute of Standards and Technology 428 (NIST), and in Public-Key Cryptography Standards (PKCS) documents. 429 The one exception is that the ASN.1 module's identifier (see Appendix 430 B.3) is assigned in this document. No further action by the IANA is 431 necessary for this document or any anticipated updates. 433 6. Acknowledgments 435 This document is one part of a strategy to align algorithm standards 436 produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would 437 like to thank the members of the ASC X9F1 working group for their 438 contributions to drafts of ANS X9.44 which led to this specification. 439 Our thanks to Russ Housley as well for his guidance and 440 encouragement. We also appreciate the helpful direction we've 441 received from Blake Ramsdell and Jim Schaad in bringing this document 442 to fruition. 444 7. Authors' Addresses 446 James Randall 447 Burt Kaliski 448 RSA Laboratories 449 174 Middlesex Turnpike 450 Bedford, MA 01730 451 USA 452 {jrandall, bkaliski}@rsasecurity.com 454 Appendix A. RSA-KEM Key Transport Algorithm 456 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 457 mechanism for transporting keying data to a recipient using the 458 recipient's RSA public key. 460 With this type of algorithm, a sender encrypts the keying data using 461 the recipient's public key to obtain encrypted keying data. The 462 recipient decrypts the encrypted keying data using the recipient's 463 private key to recover the keying data. 465 A.1 Underlying Components 467 The algorithm has the following underlying components: 469 * KDF, a key derivation function, which derives keying data of a 470 specified length from a shared secret value 472 * Wrap, a symmetric key-wrapping scheme, which encrypts keying 473 data using a key-encrypting key 475 In the following, kekLen denotes the length in bytes of the key- 476 encrypting key for the underlying symmetric key-wrapping scheme. 478 In this scheme, the length of the keying data to be transported MUST 479 be among the lengths supported by the underlying symmetric key- 480 wrapping scheme. (Bothe the AES and Camillia Key Wraps, for instance, 481 require the length of the keying data to be a multiple of 8 bytes, 482 and at least 16 bytes.) Usage and formatting of the keying data 483 (e.g., parity adjustment for Triple-DES keys) is outside the scope of 484 this algorithm. With some key derivation functions, it is possible to 485 include other information besides the shared secret value in the 486 input to the function. Also, with some symmetric key-wrapping 487 schemes, it is possible to associate a label with the keying data. 488 Such uses are outside the scope of this document, as they are not 489 directly supported by CMS. 491 A.2 Sender's Operations 493 Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) 494 and let K be the keying data to be transported. 496 Let nLen denote the length in bytes of the modulus n, i.e., the least 497 integer such that 2^{8*nLen} > n. 499 The sender performs the following operations: 501 1. Generate a random integer z between 0 and n-1 (see Note), and 502 convert z to a byte string Z of length nLen, most significant 503 byte first: 504 z = RandomInteger (0, n-1) 505 Z = IntegerToString (z, nLen) 507 2. Encrypt the random integer z using the recipient's public key 508 (n,e) and convert the resulting integer c to a ciphertext C, a 509 byte string of length nLen: 511 c = z^e mod n 512 C = IntegerToString (c, nLen) 514 3. Derive a key-encrypting key KEK of length kekLen bytes from the 515 byte string Z using the underlying key derivation function: 517 KEK = KDF (Z, kekLen) 519 4. Wrap the keying data K with the key-encrypting key KEK using 520 the underlying key-wrapping scheme to obtain wrapped keying 521 data WK: 523 WK = Wrap (KEK, K) 525 5. Concatenate the ciphertext C and the wrapped keying data WK to 526 obtain the encrypted keying data EK: 528 EK = C || WK 530 6. Output the encrypted keying data EK. 532 NOTE: The random integer z MUST be generated independently at random 533 for different encryption operations, whether for the same or 534 different recipients. 536 A.3 Recipient's Operations 538 Let (n,d) be the recipient's RSA private key (see [PKCS1]; other 539 private key formats are allowed) and let EK be the encrypted keying 540 data. 542 Let nLen denote the length in bytes of the modulus n. 544 The recipient performs the following operations: 546 1. Separate the encrypted keying data EK into a ciphertext C of 547 length nLen bytes and wrapped keying data WK: 549 C || WK = EK 551 If the length of the encrypted keying data is less than nLen 552 bytes, output "decryption error" and stop. 554 2. Convert the ciphertext C to an integer c, most significant 555 byte first. Decrypt the integer c using the recipient's 556 private key (n,d) to recover an integer z (see Note): 558 c = StringToInteger (C) 559 z = c^d mod n 561 If the integer c is not between 0 and n-1, output "decryption 562 error" and stop. 564 3. Convert the integer z to a byte string Z of length nLen, most 565 significant byte first (see Note): 567 Z = IntegerToString (z, nLen) 569 4. Derive a key-encrypting key KEK of length kekLen bytes from 570 the byte string Z using the underlying key derivation function 571 (see Note): 573 KEK = KDF (Z, kekLen) 575 5. Unwrap the wrapped keying data WK with the key-encrypting key 576 KEK using the underlying key-wrapping scheme to recover the 577 keying data K: 579 K = Unwrap (KEK, WK) 581 If the unwrapping operation outputs an error, output 582 "decryption error" and stop. 584 6. Output the keying data K. 586 NOTE: Implementations SHOULD NOT reveal information about the integer 587 z and the string Z, nor about the calculation of the exponentiation 588 in Step 2, the conversion in Step 3, or the key derivation in Step 4, 589 whether by timing or other "side channels". The observable behavior 591 of the implementation SHOULD be the same at these steps for all 592 ciphertexts C that are in range. (For example, IntegerToString 593 conversion should take the same amount of time regardless of the 594 actual value of the integer z.) The integer z, the string Z and other 595 intermediate results MUST be securely deleted when they are no longer 596 needed. 598 Appendix B. ASN.1 Syntax 600 The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm 601 is an extension of the syntax for the "generic hybrid cipher" in 602 ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in the 603 draft ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in 604 Section B.1. The syntax for selected underlying components including 605 those mentioned above is given in B.2. 607 The following object identifier prefixes are used in the definitions 608 below: 610 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 612 nistAlgorithm OID ::= { 613 joint-iso-itu-t(2) country(16) us(840) organization(1) 614 gov(101) csor(3) nistAlgorithm(4) 615 } 616 pkcs-1 OID ::= { 617 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 618 } 620 NullParms is a more descriptive synonym for NULL when an algorithm 621 identifier has null parameters: 623 NullParms ::= NULL 625 The material in this Appendix is based on a draft standard, ANS 626 X9.44, and is SUBJECT TO CHANGE as that standard is developed. 628 B.1 RSA-KEM Key Transport Algorithm 630 The object identifier for the RSA-KEM Key Transport Algorithm is the 631 same as for the "generic hybrid cipher" in the draft ANS ISO/IEC 632 18033-2, id-ac-generic-hybrid, which is defined in the draft as 634 id-ac-generic-hybrid OID ::= { 635 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 636 } 638 The associated parameters for id-ac-generic-hybrid have type 639 GenericHybridParameters: 641 GenericHybridParameters ::= { 642 kem KeyEncapsulationMechanism, 643 dem DataEncapsulationMechanism 644 } 646 The fields of type GenericHybridParameters have the following 647 meanings: 649 * kem identifies the underlying key encapsulation mechanism. For 650 the RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from 651 ISO/IEC 18033-2. 653 The object identifier for RSA-KEM (as a key encapsulation 654 mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 655 as 657 id-kem-rsa OID ::= { 658 is18033-2 key-encapsulation-mechanism(2) rsa(4) 659 } 661 The associated parameters for id-kem-rsa have type 662 RsaKemParameters: 664 RsaKemParameters ::= { 665 keyDerivationFunction KeyDerivationFunction, 666 keyLength KeyLength 667 } 669 The fields of type RsaKemParameters have the following 670 meanings: 672 * keyDerivationFunction identifies the underlying key 673 derivation function. For alignment with the draft ANS 674 X9.44, it MUST be KDF2 or KDF3. However, other key 675 derivation functions MAY be used with CMS. Please see 676 B.2.1 for the syntax for KDF2 and KDF3. 678 KeyDerivationFunction ::= 679 AlgorithmIdentifier {{KDFAlgorithms}} 681 KDFAlgorithms ALGORITHM ::= { 682 kdf2 | kdf3, 683 ... -- implementations may define other methods 684 } 686 * keyLength is the length in bytes of the key-encrypting 687 key, which depends on the underlying symmetric key- 688 wrapping scheme. 689 KeyLength ::= INTEGER (1..MAX) 691 * dem identifies the underlying data encapsulation mechanism. 692 For alignment with the draft ANS X9.44, it MUST be an X9- 693 approved symmetric key-wrapping scheme. (See Note.) However, 694 other symmetric key-wrapping schemes MAY be used with CMS. 695 Please see B.2.2 for the syntax for the AES, Triple-DES, and 696 Camillia Key Wraps. 698 DataEncapsulationMechanism ::= 699 AlgorithmIdentifier {{DEMAlgorithms}} 701 DEMAlgorithms ALGORITHM ::= { 702 X9-SymmetricKeyWrappingSchemes, 703 Camillia-KeyWrappingSchemes, 704 ... -- implementations may define other methods 705 } 707 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 708 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 709 ... -- allows for future expansion 710 } 711 Camillia-KeyWrappingSchemes ALGORITHM ::= { 712 camillia128-Wrap | camillia192-Wrap | camillia256-Wrap 713 } 715 NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt 716 arbitrary data, hence the term "data encapsulation mechanism". The 717 symmetric key-wrapping schemes take the role of data encapsulation 718 mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2 719 allows only three specific data encapsulation mechanisms, not 720 including any of these symmetric key-wrapping schemes. However, the 721 ASN.1 syntax in that document expects that additional algorithms will 722 be allowed. 724 B.2 Selected Underlying Components 726 B.2.1 Key Derivation Functions 728 The object identifier for KDF2 (see [ISO-IEC-18033-2]) is 730 The associated parameters identify the underlying hash function. For 731 alignment with the draft ANS X9.44, the hash function MUST be an ASC 732 X9-approved hash function. However, other hash functions MAY be used 733 with CMS. 735 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 737 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 739 KDF2-HashFunctions ALGORITHM ::= { 740 X9-HashFunctions, 741 ... -- implementations may define other methods 742 } 744 X9-HashFunctions ALGORITHM ::= { 745 sha1 | sha224 | sha256 | sha384 | sha512, 746 ... -- allows for future expansion 747 } 749 The object identifier for SHA-1 is 751 id-sha1 OID ::= { 752 iso(1) identified-organization(3) oiw(14) secsig(3) 753 algorithms(2) sha1(26) 754 } 756 The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are 758 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } 759 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 760 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 761 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 763 There has been some confusion over whether the various SHA object 764 identifiers have a NULL parameter, or no associated parameters. As 765 also discussed in [PKCS1], implementations SHOULD generate algorithm 766 identifiers without parameters, and MUST accept algorithm identifiers 767 either without parameters, or with NULL parameters. 769 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be 770 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 771 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 772 sha384 ALGORITHM ::= {{ OID id-sha384 }} �- "" 773 sha512 ALGORITHM ::= {{ OID id-sha512 }} �- "" 775 The object identifier for KDF3 is: 777 id-kdf-kdf3 OID ::= { 778 to be assigned 779 } 781 The associated parameters identify the underlying hash function. For 782 alignment with the draft ANS X9.44, the hash function MUST be an ASC 783 X9-approved hash function. (See Note.) However, other hash functions 784 MAY be used with CMS. 786 kdf3 ALGORITHM ::= {{ OID id-kdf-kdf3 PARMS KDF3-HashFunction }} 788 KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} 790 KDF3-HashFunctions ALGORITHM ::= { 791 X9-HashFunctions, 792 ... -- implementations may define other methods 793 } 795 B.2.2 Symmetric Key-Wrapping Schemes 797 The object identifiers for the AES Key Wrap depends on the size of 798 the key encrypting key. There are three object identifiers (see 799 [AES-WRAP]): 801 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 802 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 803 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 805 These object identifiers have no associated parameters. 807 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 808 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 809 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 811 The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) 812 is 814 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 815 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 816 smime(16) alg(3) 6 817 } 819 This object identifier has a NULL parameter. 821 tdes-Wrap ALGORITHM ::= 822 {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 824 NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key 825 Wrap are in the process of being approved by ASC X9. 827 The object identifiers for the Camillia Key Wrap depends on the size of 828 the key encrypting key. There are three object identifiers: 830 id-camellia128-Wrap OBJECT IDENTIFIER ::= 831 { iso(1) member-body(2) 392 200011 61 security(1) 832 algorithm(1) key-wrap-algorithm(3) 833 camellia128-wrap(2) } 835 id-camellia192-Wrap OBJECT IDENTIFIER ::= 836 { iso(1) member-body(2) 392 200011 61 security(1) 837 algorithm(1) key-wrap-algorithm(3) 838 camellia192-wrap(3) } 840 id-camellia256-Wrap OBJECT IDENTIFIER ::= 841 { iso(1) member-body(2) 392 200011 61 security(1) 842 algorithm(1) key-wrap-algorithm(3) 843 camellia256-wrap(4) } 845 These object identifiers have no associated parameters. 847 camellia128-Wrap ALGORITHM ::= {{ OID id-camellia128-wrap }} 848 camellia192-Wrap ALGORITHM ::= {{ OID id-camellia192-wrap }} 849 camellia256-Wrap ALGORITHM ::= {{ OID id-camellia256-wrap }} 851 B.3 ASN.1 module 853 CMS-RSA-KEM 854 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 855 pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } [[check]] 857 BEGIN 859 -- EXPORTS ALL 861 -- IMPORTS None 863 -- Useful types and definitions 865 OID ::= OBJECT IDENTIFIER -- alias 867 -- Unless otherwise stated, if an object identifier has associated 868 -- parameters (i.e., the PARMS element is specified), the parameters 869 -- field shall be included in algorithm identifier values. The 870 -- parameters field shall be omitted if and only if the object 871 -- identifier does not have associated parameters (i.e., the PARMS 872 -- element is omitted), unless otherwise stated. 874 ALGORITHM ::= CLASS { 875 &id OBJECT IDENTIFIER UNIQUE, 876 &Type OPTIONAL 877 } 878 WITH SYNTAX { OID &id [PARMS &Type] } 880 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 881 algorithm ALGORITHM.&id( {IOSet} ), 882 parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL 883 } 885 NullParms ::= NULL 887 -- ISO/IEC 18033-2 arc 889 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 891 -- NIST algorithm arc 893 nistAlgorithm OID ::= { 894 joint-iso-itu-t(2) country(16) us(840) organization(1) 895 gov(101) csor(3) nistAlgorithm(4) 896 } 898 -- PKCS #1 arc 900 pkcs-1 OID ::= { 901 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 902 } 903 -- RSA-KEM Key Transport Algorithm, based on Generic Hybrid Cipher 905 id-ac-generic-hybrid OID ::= { 906 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 907 } 909 GenericHybridParameters ::= { 910 kem KeyEncapsulationMechanism, 911 dem DataEncapsulationMechanism 912 } 914 id-kem-rsa OID ::= { 915 is18033-2 key-encapsulation-mechanism(2) rsa(4) 916 } 918 RsaKemParameters ::= { 919 keyDerivationFunction KeyDerivationFunction, 920 keyLength KeyLength 921 } 923 KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} 925 KDFAlgorithms ALGORITHMS ::= { 926 kdf2 | kdf3, 927 ... -- implementations may define other methods 928 } 930 KeyLength ::= INTEGER (1..MAX) 932 DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} 934 DEMAlgorithms ALGORITHM ::= { 935 X9-SymmetricKeyWrappingSchemes, 936 Camillia-KeyWrappingSchemes, 937 ... -- implementations may define other methods 938 } 940 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 941 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 942 ... -- allows for future expansion 943 } 945 Camillia-KeyWrappingSchemes ALGORITHM ::= { 946 camillia128-Wrap | camillia192-Wrap | camillia128-Wrap 947 } 948 -- Key Derivation Functions 950 id-kdf-kdf2 OID ::= { is18033-2 key-derivation-functions(5) kdf2(2) } 952 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 954 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 956 KDF2-HashFunctions ALGORITHM ::= { 957 X9-HashFunctions, 958 ... -- implementations may define other methods 959 } 961 -- id-kdf-kdf3 OID ::= (to be assigned) 963 kdf3 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF3-HashFunction }} 965 KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} 967 KDF3-HashFunctions ALGORITHM ::= { 968 X9-HashFunctions, 969 ... -- implementations may define other methods 970 } 972 -- Hash Functions 974 X9-HashFunctions ALGORITHM ::= { 975 sha1 | sha224 | sha256 | sha384 | sha512, 976 ... -- allows for future expansion 977 } 979 id-sha1 OID ::= { 980 iso(1) identified-organization(3) oiw(14) secsig(3) 981 algorithms(2) sha1(26) 982 } 984 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha256(4) } 985 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 986 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 987 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 989 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NullParms MUST be 990 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 991 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 992 sha384 ALGORITHM ::= {{ OID id-sha384 }} �- "" 993 sha512 ALGORITHM ::= {{ OID id-sha512 }} �- "" 995 -- Symmetric Key-Wrapping Schemes 997 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 998 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 999 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 1000 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 1001 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 1002 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 1004 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 1005 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1006 smime(16) alg(3) 6 1007 } 1009 tdes-Wrap ALGORITHM ::= {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 1011 id-camellia128-Wrap OBJECT IDENTIFIER ::= 1012 { iso(1) member-body(2) 392 200011 61 security(1) 1013 algorithm(1) key-wrap-algorithm(3) 1014 camellia128-wrap(2) } 1016 id-camellia192-Wrap OBJECT IDENTIFIER ::= 1017 { iso(1) member-body(2) 392 200011 61 security(1) 1018 algorithm(1) key-wrap-algorithm(3) 1019 camellia192-wrap(3) } 1021 id-camellia256-Wrap OBJECT IDENTIFIER ::= 1022 { iso(1) member-body(2) 392 200011 61 security(1) 1023 algorithm(1) key-wrap-algorithm(3) 1024 camellia256-wrap(4) } 1026 camellia128-Wrap ALGORITHM ::= {{ OID id-camellia128-wrap }} 1027 camellia192-Wrap ALGORITHM ::= {{ OID id-camellia192-wrap }} 1028 camellia256-Wrap ALGORITHM ::= {{ OID id-camellia256-wrap }} 1030 B.4 Examples 1032 As an example, if the key derivation function is KDF2 based on 1033 SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap 1034 with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key 1035 Transport Algorithm will have the following value: 1037 SEQUENCE { 1038 id-ac-generic-hybrid, -- generic cipher 1039 SEQUENCE { -- GenericHybridParameters 1040 SEQUENCE { -- key encapsulation mechanism 1041 id-kem-rsa, -- RSA-KEM 1042 SEQUENCE { -- RsaKemParameters 1043 SEQUENCE { -- key derivation function 1044 id-kdf-kdf2, -- KDF2 1045 SEQUENCE { -- KDF2-HashFunction 1046 id-sha256 -- SHA-256; no parameters (preferred) 1047 }, 1048 16 -- KEK length in bytes 1049 }, 1050 SEQUENCE { -- data encapsulation mechanism 1051 id-aes128-Wrap -- AES-128 Wrap; no parameters 1052 } 1053 } 1054 } 1056 This AlgorithmIdentifier value has the following DER encoding: 1058 30 4f 1059 06 07 28 81 8c 71 02 01 02 -- id-ac-generic-hybrid 1060 30 44 1061 30 25 1062 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 1063 30 1a 1064 30 16 1065 06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 1066 30 0b 1067 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 1068 02 10 -- 16 bytes 1069 30 0b 1070 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 1072 The DER encodings for other typical sets of underlying components are 1073 as follows: 1075 * KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK 1077 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 1078 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 1079 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 1080 02 02 02 18 30 0b 06 09 60 86 48 01 65 03 04 01 1081 19 1083 * KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK 1085 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 1086 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 1087 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 1088 02 03 02 20 30 0b 06 09 60 86 48 01 65 03 04 01 1089 2d 1091 * KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK 1092 (two-key triple-DES) 1094 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 1095 07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81 1096 8c 71 02 05 02 30 07 06 05 2b 0e 03 02 1a 02 10 1097 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 1098 00 1100 * KDF2 based on SHA-224, Triple-DES Key Wrap with a 192-bit 1101 KEK (three-key triple-DES) 1103 [[to be defined]] 1105 Full Copyright Statement 1107 Copyright (C) The Internet Society (2003). All Rights Reserved. 1109 This document and translations of it may be copied and furnished to 1110 others, and derivative works that comment on or otherwise explain it 1111 or assist in its implementation may be prepared, copied, published 1112 and distributed, in whole or in part, without restriction of any 1113 kind, provided that the above copyright notice and this paragraph 1114 are included on all such copies and derivative works. However, this 1115 document itself may not be modified in any way, such as by removing 1116 the copyright notice or references to the Internet Society or other 1117 Internet organizations, except as needed for the purpose of 1118 developing Internet standards in which case the procedures for 1119 copyrights defined in the Internet Standards process must be 1120 followed, or as required to translate it into languages other than 1121 English. 1123 The limited permissions granted above are perpetual and will not be 1124 revoked by the Internet Society or its successors or assigns.