idnits 2.17.1 draft-ietf-smime-cms-rsa-kem-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 25. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 32. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 38. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 2007) is 6101 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) ** Downref: Normative reference to an Informational RFC: RFC 3217 (ref. '3DES-WRAP') ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'AES-WRAP') ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' ** Obsolete normative reference: RFC 3851 (ref. 'MSG') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group J. Randall 3 Internet Draft RSA 4 Document: draft-ietf-smime-cms-rsa-kem-04.txt B.Kaliski 5 Category: Standards EMC Corp. 6 July 2007 8 Use of the RSA-KEM Key Transport Algorithm in CMS 9 11 Intellectual Property 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 The IETF takes no position regarding the validity or scope of any 19 Intellectual Property Rights or other rights that might be claimed to 20 pertain to the implementation or use of the technology described in 21 this document or the extent to which any license under such rights 22 might or might not be available; nor does it represent that it has 23 made any independent effort to identify any such rights. Information 24 on the procedures with respect to rights in RFC documents can be 25 found in BCP 78 and BCP 79. 27 Copies of IPR disclosures made to the IETF Secretariat and any 28 assurances of licenses to be made available, or the result of an 29 attempt made to obtain a general license or permission for the use of 30 such proprietary rights by implementers or users of this 31 specification can be obtained from the IETF on-line IPR repository at 32 http://www.ietf.org/ipr. 34 The IETF invites any interested party to bring to its attention any 35 copyrights, patents or patent applications, or other proprietary 36 rights that may cover technology that may be required to implement 37 this standard. Please address the information to the IETF at 38 ietf-ipr@ietf.org. 40 Copyright (C) The IETF Trust (2007). 42 This document is subject to the rights, licenses and restrictions 43 contained in BCP 78, and except as set forth therein, the authors 44 retain all their rights. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that other 48 groups may also distribute working documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at: 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at: 57 http://www.ietf.org/shadow.html 59 Comments or suggestions for improvement may be made on the "ietf- 60 smime" mailing list, or directly to the author. 62 Abstract 64 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 65 mechanism for transporting keying data to a recipient using the 66 recipient's RSA public key. This document specifies the conventions 67 for using the RSA-KEM Key Transport Algorithm with the Cryptographic 68 Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and 69 ISO/IEC 18033-2. 71 Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 75 this document are to be interpreted as described in RFC 2119 76 [STDWORDS]. 78 1. Introduction 80 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 81 mechanism for transporting keying data to a recipient using the 82 recipient's RSA public key. 84 Most previous key transport algorithms based on the RSA public-key 85 cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have 86 the following general form: 88 1. Format or "pad" the keying data to obtain an integer m. 90 2. Encrypt the integer m with the recipient's RSA public key: 92 c = m^e mod n 94 3. Output c as the encrypted keying data. 96 The RSA-KEM Key Transport Algorithm takes a different approach that 97 provides higher security assurance, by encrypting a _random_ integer 98 with the recipient's public key, and using a symmetric key-wrapping 99 scheme to encrypt the keying data. It has the following form: 101 1. Generate a random integer z between 0 and n-1. 103 2. Encrypt the integer z with the recipient's RSA public key: 105 c = z^e mod n. 107 3. Derive a key-encrypting key KEK from the integer z. 109 4. Wrap the keying data using KEK to obtain wrapped keying data 110 WK. 112 5. Output c and WK as the encrypted keying data. 114 This different approach provides higher security assurance because 115 the input to the underlying RSA operation is random and independent 116 of the message, and the key-encrypting key KEK is derived from it in 117 a strong way. As a result, the algorithm enjoys a "tight" security 118 proof in the random oracle model. It is also architecturally 119 convenient because the public-key operations are separate from the 120 symmetric operations on the keying data. One benefit is that the 121 length of the keying data is bounded only by the symmetric key- 122 wrapping scheme, not the size of the RSA modulus. 124 The RSA-KEM Key Transport Algorithm in various forms is being adopted 125 in several draft standards as well as in ANS-X9.44 and ISO/IEC 126 18033-2. It has also been recommended by the NESSIE project [NESSIE]. 127 For completeness, a specification of the algorithm is given in 128 Appendix A of this document; ASN.1 syntax is given in Appendix B. 130 NOTE: The term KEM stands for "key encapsulation mechanism" and 131 refers to the first three steps of the process above. The 132 formalization of key transport algorithms (or more generally, 133 asymmetric encryption schemes) in terms of key encapsulation 134 mechanisms is described further in research by Victor Shoup leading 135 to the development of the ISO/IEC 18033-2 standard [SHOUP]. 137 2. Use in CMS 139 The RSA-KEM Key Transport Algorithm MAY be employed for one or more 140 recipients in the CMS enveloped-data content type (Section 6 of 141 [CMS]), where the keying data processed by the algorithm is the CMS 142 content-encryption key. 144 The RSA-KEM Key Transport Algorithm SHOULD be considered for new 145 CMS-based applications as a replacement for the widely implemented 146 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see 147 [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to 148 chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm 149 has also been proposed as a replacement (see [PKCS1] and [CMS- 150 OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter 151 security proof, but the disadvantage of slightly longer encrypted 152 keying data. 154 2.1 Underlying Components 156 A CMS implementation that supports the RSA-KEM Key Transport 157 Algorithm MUST support at least the following underlying components: 159 * For the key derivation function, KDF2 or KDF3 (see [ANS-X9.44] 160 [IEEE-P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function 161 is also specified as the key derivation function in 162 [ANS-X9.63]). 164 * For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key 165 Wrap with a 128-bit key encrypting key (see [AES-WRAP]) 167 An implementation SHOULD also support KDF2 and KDF3 based on SHA-256 168 (see [FIPS-180-2]). The Camillia key wrap algorithm (see [CAMILLIA]) 169 should be supported, and, if 3DES is supported as a content- 170 encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP]) 171 SHOULD also be supported. 173 It MAY support other underlying components. When AES or Camilla are 174 used the data block size is 128 bits while the key size can be 128, 175 192, or 256 bits while Triple DES requires a data block size of 64 176 bits and a key size of 112 or 168 bits. 178 2.2 RecipientInfo Conventions 180 When the RSA-KEM Key Transport Algorithm is employed for a recipient, 181 the RecipientInfo alternative for that recipient MUST be 183 KeyTransRecipientInfo. The algorithm-specific fields of the 184 KeyTransRecipientInfo value MUST have the following values: 186 * keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid 187 (see Appendix B) 189 * keyEncryptionAlgorithm.parameters MUST be a value of type 190 GenericHybridParameters, identifying the RSA-KEM key 191 encapsulation mechanism (see Appendix B) 193 * encryptedKey MUST be the encrypted keying data output by the 194 algorithm, where the keying data is the content-encryption key. 195 (see Appendix A) 197 2.3 Certificate Conventions 199 The conventions specified in this section augment RFC 3280 [PROFILE]. 201 A recipient who employs the RSA-KEM Key Transport Algorithm MAY 202 identify the public key in a certificate by the same 203 AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using 204 the rsaEncryption object identifier [PKCS1]. 206 If the recipient wishes only to employ the RSA-KEM Key Transport 207 Algorithm with a given public key, the recipient MUST identify the 208 public key in the certificate using the id-ac-generic-hybrid object 209 identifier (see Appendix B) where the associated 210 GenericHybridParameters value indicates the underlying components 211 with which the algorithm is to be employed. The certificate user MUST 212 perform the RSA-KEM Key Transport algorithm using only those 213 components. 215 Regardless of the AlgorithmIdentifier used, the RSA public key is 216 encoded in the same manner in the subject public key information. 217 The RSA public key MUST be encoded using the type RSAPublicKey type: 219 RSAPublicKey ::= SEQUENCE { 220 modulus INTEGER, -- n 221 publicExponent INTEGER -- e 222 } 224 Here, the modulus is the modulus n, and publicExponent is the public 225 exponent e. The DER encoded RSAPublicKey is carried in the 226 subjectPublicKey BIT STRING within the subject public key 227 information. 229 The intended application for the key MAY be indicated in the key 230 usage certificate extension (see [PROFILE], Section 4.2.1.3). If the 231 keyUsage extension is present in a certificate that conveys an RSA 232 public key with the id-ac-generic-hybrid object identifier as 233 discussed above, then the key usage extension MUST contain the 234 following value: 236 keyEncipherment. 238 dataEncipherment SHOULD NOT be present. That is, a key intended to be 239 employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT 240 also be employed for data encryption or for authentication such as in 241 signatures. Good cryptographic practice employs a given RSA key pair 242 in only one scheme. This practice avoids the risk that vulnerability 243 in one scheme may compromise the security of the other, and may be 244 essential to maintain provable security. 246 2.4 SMIMECapabilities Attribute Conventions 248 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 249 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 250 used to specify a partial list of algorithms that the software 251 announcing the SMIMECapabilities can support. When constructing a 252 signedData object, compliant software MAY include the 253 SMIMECapabilities signed attribute announcing that it supports the 254 RSA-KEM Key Transport algorithm. 256 The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport 257 Algorithm MUST include the id-ac-generic-hybrid object identifier 258 (see Appendix B) in the capabilityID field and MUST include a 259 GenericHybridParameters value in the parameters field identifying the 260 components with which the algorithm is to be employed. 262 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 263 encoding of an AlgorithmIdentifier. Example DER encodings for typical 264 sets of components are given in Appendix B.4. 266 3. Security Considerations 268 The security of the RSA-KEM Key Transport Algorithm described in 269 this document can be shown to be tightly related to the difficulty 270 of either solving the RSA problem or breaking the underlying 271 symmetric key-wrapping scheme, if the underlying key derivation 272 function is modeled as a random oracle, and assuming that the 273 symmetric key-wrapping scheme satisfies the properties of a data 274 encapsulation mechanism [SHOUP]. While in practice a random-oracle 275 result does not provide an actual security proof for any particular 276 key derivation function, the result does provide assurance that the 277 general construction is reasonable; a key derivation function would 278 need to be particularly weak to lead to an attack that is not 279 possible in the random oracle model. 281 The RSA key size and the underlying components should be selected 282 consistent with the desired symmetric security level for an 283 application. Several security levels have been identified in [NIST- 284 FIPS PUB 800-57]. For brevity, the first three levels are mentioned 285 here: 287 * 80-bit security. The RSA key size SHOULD be at least 1024 bits, 288 the hash function underlying the KDF SHOULD be SHA-1 or above, 289 and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, 290 Triple-DES Key Wrap, or Camillia Key Wrap. 292 * 112-bit security. The RSA key size SHOULD be at least 2048 293 bits, the hash function underlying the KDF SHOULD be SHA-224 or 294 above, and the symmetric key-wrapping scheme SHOULD be AES Key 295 Wrap, Triple-DES Key Wrap, or Camillia Key Wrap. 297 * 128-bit security. The RSA key size SHOULD be at least 3072 298 bits, the hash function underlying the KDF SHOULD be SHA-256 or 299 above, and the symmetric key-wrapping scheme SHOULD be AES Key 300 Wrap or Camillia Key Wrap. 302 Note that the AES Key Wrap or Camillia Key Wrap MAY be used at all 303 three of these levels; the use of AES or Camillia does not require a 304 128-bit security level for other components. 306 Implementations MUST protect the RSA private key and the content- 307 encryption key. Compromise of the RSA private key may result in the 308 disclosure of all messages protected with that key. Compromise of the 309 content-encryption key may result in disclosure of the associated 310 encrypted content. 312 Additional considerations related to key management may be found in 313 [NIST-GUIDELINE]. 315 The security of the algorithm also depends on the strength of the 316 random number generator, which SHOULD have a comparable security 317 level. For further discussion on random number generation, please 318 see [RANDOM]. 320 Implementations SHOULD NOT reveal information about intermediate 321 values or calculations, whether by timing or other "side channels", 322 or otherwise an opponent may be able to determine information about 323 the keying data and/or the recipient's private key. Although not all 324 intermediate information may be useful to an opponent, it is 325 preferable to conceal as much information as is practical, unless 326 analysis specifically indicates that the information would not be 327 useful. 329 Generally, good cryptographic practice employs a given RSA key pair 330 in only one scheme. This practice avoids the risk that vulnerability 331 in one scheme may compromise the security of the other, and may be 332 essential to maintain provable security. While RSA public keys have 333 often been employed for multiple purposes such as key transport and 334 digital signature without any known bad interactions, for increased 335 security assurance, such combined use of an RSA key pair is NOT 336 RECOMMENDED in the future (unless the different schemes are 337 specifically designed to be used together). 339 Accordingly, an RSA key pair used for the RSA-KEM Key Transport 340 Algorithm SHOULD NOT also be used for digital signatures. (Indeed, 341 ASC X9 requires such a separation between key establishment key pairs 342 and digital signature key pairs.) Continuing this principle of key 343 separation, a key pair used for the RSA-KEM Key Transport Algorithm 344 SHOULD NOT be used with other key establishment schemes, or for data 345 encryption, or with more than one set of underlying algorithm 346 components. 348 Parties MAY formalize the assurance that one another's 349 implementations are correct through implementation validation, e.g. 350 NIST's Cryptographic Module Validation Program (CMVP). 352 4. References 354 4.1 Normative References 356 [3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC 357 3217. December 2001. 359 [AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption 360 Standard (AES) Key Wrap Algorithm. RFC 3394. 361 September 2002. 363 [ANS-X9.63] American National Standard X9.63-2002: Public Key 364 Cryptography for the Financial Services Industry: 365 Key Agreement and Key Transport Using Elliptic 366 Curve Cryptography. 368 [CAMILLIA] Kato, A., Moriai, S., and Kanda, M.: The Camellia 369 Cipher Algorithm and Its Use With IPsec. RFC 4312. 370 December 2005 372 [CMS] Housley, R. Cryptographic Message Syntax. RFC 373 3852. July 2004. 375 [CMSALGS] Housley, R. Cryptographic Message Syntax (CMS) 376 Algorithms. RFC 3370. August 2002. 378 [FIPS-180-2] National Institute of Standards and Technology 379 (NIST). FIPS 180-2: Secure Hash Standard. August 380 2002. 382 [MSG] Ramsdell, B. S/MIME Version 3 Message 383 Specification. RFC 3851. July 2004. 385 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo. 386 Internet X.509 Public Key Infrastructure: 387 Certificate and Certificate Revocation List (CRL) 388 Profile. RFC 3280. April 2002. 390 [STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate 391 Requirement Levels. RFC 2119. March 1997. 393 4.2 Informative References 395 [ANS-X9.44] ASC X9F1 Working Group. American National 396 Standard X9.44: Public Key Cryptography for the 397 Financial Services Industry -- Key Establishment 398 Using Integer Factorization Cryptography. 2007 400 [CMS-OAEP] Housley, R. Use of the RSAES-OAEP Key Transport 401 Algorithm in the Cryptographic Message Syntax 402 (CMS). RFC 3560. July 2003. 404 [IEEE-P1363a] IEEE Std 1363a-2004: Standard Specifications for 405 Public Key Cryptography: Additional Techniques. 406 IEEE, 2004. 408 [ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- 409 Security techniques -- Encryption algorithms -- 410 Part 2: Asymmetric Ciphers. ISO/IEC, 2005. 412 [NESSIE] NESSIE Consortium. Portfolio of Recommended 413 Cryptographic Primitives. February 27, 2003. 414 Available via http://www.cryptonessie.org/. 416 [NIST-GUIDELINE] National Institute of Standards and Technology. 417 Special Publication 800-57: Recommendation for Key 418 Management. Part 1: General Guideline. August 2005. 419 Available via: 420 http://csrc.nist.gov/publications/index.html. 422 [PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA 423 Cryptography Specifications Version 2.1. RFC 3447. 424 February 2003. 426 [RANDOM] Eastlake, D., S. Crocker, and J. Schiller. 427 Randomness Recommendations for Security. RFC 4086. 428 June 2005. 430 [SHOUP] Shoup, V. A Proposal for an ISO Standard for 431 Public Key Encryption. Version 2.1, December 20, 432 2001. Available via http://www.shoup.net/papers/. 434 5. IANA Considerations 436 Within the CMS, algorithms are identified by object identifiers 437 (OIDs). With one exception, all of the OIDs used in this document 438 were assigned in other IETF documents, in ISO/IEC standards 440 documents, by the National Institute of Standards and Technology 441 (NIST), and in Public-Key Cryptography Standards (PKCS) documents. 442 The one exception is that the ASN.1 module's identifier (see Appendix 443 B.3) is assigned in this document. No further action by the IANA is 444 necessary for this document or any anticipated updates. 446 6. Acknowledgments 448 This document is one part of a strategy to align algorithm standards 449 produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would 450 like to thank the members of the ASC X9F1 working group for their 451 contributions to drafts of ANS X9.44 which led to this specification. 452 Our thanks to Russ Housley as well for his guidance and 453 encouragement. We also appreciate the helpful direction we've 454 received from Blake Ramsdell and Jim Schaad in bringing this document 455 to fruition. 457 7. Authors' Addresses 459 James Randall 460 RSA, The Security Division of EMC 461 174 Middlesex Turnpike 462 Bedford, MA 01730 463 USA 464 e-mail: jrandall@rsasecurity.com 466 Burt Kaliski 467 EMC 468 176 South Street 469 Hopkinton, MA 01748 470 USA 471 e-mail: kaliski_burt@emc.com 473 Appendix A. RSA-KEM Key Transport Algorithm 474 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 475 mechanism for transporting keying data to a recipient using the 476 recipient's RSA public key. 478 With this type of algorithm, a sender encrypts the keying data using 479 the recipient's public key to obtain encrypted keying data. The 480 recipient decrypts the encrypted keying data using the recipient's 481 private key to recover the keying data. 483 A.1 Underlying Components 485 The algorithm has the following underlying components: 487 * KDF, a key derivation function, which derives keying data of a 488 specified length from a shared secret value 490 * Wrap, a symmetric key-wrapping scheme, which encrypts keying 491 data using a key-encrypting key 493 In the following, kekLen denotes the length in bytes of the key- 494 encrypting key for the underlying symmetric key-wrapping scheme. 496 In this scheme, the length of the keying data to be transported MUST 497 be among the lengths supported by the underlying symmetric key- 498 wrapping scheme. (Both the AES and Camillia Key Wraps, for instance, 499 require the length of the keying data to be a multiple of 8 bytes, 500 and at least 16 bytes.) Usage and formatting of the keying data 501 (e.g., parity adjustment for Triple-DES keys) is outside the scope of 502 this algorithm. With some key derivation functions, it is possible to 503 include other information besides the shared secret value in the 504 input to the function. Also, with some symmetric key-wrapping 505 schemes, it is possible to associate a label with the keying data. 506 Such uses are outside the scope of this document, as they are not 507 directly supported by CMS. 509 A.2 Sender's Operations 511 Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) 512 and let K be the keying data to be transported. 514 Let nLen denote the length in bytes of the modulus n, i.e., the least 515 integer such that 2^{8*nLen} > n. 517 The sender performs the following operations: 519 1. Generate a random integer z between 0 and n-1 (see Note), and 520 convert z to a byte string Z of length nLen, most significant 521 byte first: 522 z = RandomInteger (0, n-1) 523 Z = IntegerToString (z, nLen) 525 2. Encrypt the random integer z using the recipient's public key 526 (n,e) and convert the resulting integer c to a ciphertext C, a 527 byte string of length nLen: 529 c = z^e mod n 530 C = IntegerToString (c, nLen) 532 3. Derive a key-encrypting key KEK of length kekLen bytes from the 533 byte string Z using the underlying key derivation function: 535 KEK = KDF (Z, kekLen) 537 4. Wrap the keying data K with the key-encrypting key KEK using 538 the underlying key-wrapping scheme to obtain wrapped keying 539 data WK: 541 WK = Wrap (KEK, K) 543 5. Concatenate the ciphertext C and the wrapped keying data WK to 544 obtain the encrypted keying data EK: 546 EK = C || WK 548 6. Output the encrypted keying data EK. 550 NOTE: The random integer z MUST be generated independently at random 551 for different encryption operations, whether for the same or 552 different recipients. 554 A.3 Recipient's Operations 556 Let (n,d) be the recipient's RSA private key (see [PKCS1]; other 557 private key formats are allowed) and let EK be the encrypted keying 558 data. 560 Let nLen denote the length in bytes of the modulus n. 562 The recipient performs the following operations: 564 1. Separate the encrypted keying data EK into a ciphertext C of 565 length nLen bytes and wrapped keying data WK: 567 C || WK = EK 569 If the length of the encrypted keying data is less than nLen 570 bytes, output "decryption error" and stop. 572 2. Convert the ciphertext C to an integer c, most significant 573 byte first. Decrypt the integer c using the recipient's 574 private key (n,d) to recover an integer z (see Note): 576 c = StringToInteger (C) 577 z = c^d mod n 578 If the integer c is not between 0 and n-1, output "decryption 579 error" and stop. 581 3. Convert the integer z to a byte string Z of length nLen, most 582 significant byte first (see Note): 584 Z = IntegerToString (z, nLen) 586 4. Derive a key-encrypting key KEK of length kekLen bytes from 587 the byte string Z using the underlying key derivation function 588 (see Note): 589 KEK = KDF (Z, kekLen) 591 5. Unwrap the wrapped keying data WK with the key-encrypting key 592 KEK using the underlying key-wrapping scheme to recover the 593 keying data K: 595 K = Unwrap (KEK, WK) 597 If the unwrapping operation outputs an error, output 598 "decryption error" and stop. 600 6. Output the keying data K. 602 NOTE: Implementations SHOULD NOT reveal information about the integer 603 z and the string Z, nor about the calculation of the exponentiation 604 in Step 2, the conversion in Step 3, or the key derivation in Step 4, 605 whether by timing or other "side channels". The observable behavior 607 of the implementation SHOULD be the same at these steps for all 608 ciphertexts C that are in range. (For example, IntegerToString 609 conversion should take the same amount of time regardless of the 610 actual value of the integer z.) The integer z, the string Z and other 611 intermediate results MUST be securely deleted when they are no longer 612 needed. 614 Appendix B. ASN.1 Syntax 616 The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm 617 is an extension of the syntax for the "generic hybrid cipher" in 618 ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in 619 ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section 620 B.1. The syntax for selected underlying components including those 621 mentioned above is given in B.2. 623 The following object identifier prefixes are used in the definitions 624 below: 626 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 628 nistAlgorithm OID ::= { 629 joint-iso-itu-t(2) country(16) us(840) organization(1) 630 gov(101) csor(3) nistAlgorithm(4) 631 } 632 pkcs-1 OID ::= { 633 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 634 } 636 NullParms is a more descriptive synonym for NULL when an algorithm 637 identifier has null parameters: 639 NullParms ::= NULL 641 The material in this Appendix is based on ANS X9.44. 643 B.1 RSA-KEM Key Transport Algorithm 645 The object identifier for the RSA-KEM Key Transport Algorithm is the 646 same as for the "generic hybrid cipher" in ISO/IEC 18033-2, 647 id-ac-generic-hybrid, which is defined in the draft as: 649 id-ac-generic-hybrid OID ::= { 650 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 651 } 653 The associated parameters for id-ac-generic-hybrid have type 654 GenericHybridParameters: 656 GenericHybridParameters ::= { 657 kem KeyEncapsulationMechanism, 658 dem DataEncapsulationMechanism 659 } 661 The fields of type GenericHybridParameters have the following 662 meanings: 664 * kem identifies the underlying key encapsulation mechanism. For 665 the RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from 666 ISO/IEC 18033-2. 668 The object identifier for RSA-KEM (as a key encapsulation 669 mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 670 as 672 id-kem-rsa OID ::= { 673 is18033-2 key-encapsulation-mechanism(2) rsa(4) 674 } 676 The associated parameters for id-kem-rsa have type 677 RsaKemParameters: 679 RsaKemParameters ::= { 680 keyDerivationFunction KeyDerivationFunction, 681 keyLength KeyLength 682 } 684 The fields of type RsaKemParameters have the following 685 meanings: 687 * keyDerivationFunction identifies the underlying key 688 derivation function. For alignment with ANS X9.44, it 689 MUST be KDF2 or KDF3. However, other key derivation 690 functions MAY be used with CMS. Please see B.2.1 for the 691 syntax for KDF2 and KDF3. 693 KeyDerivationFunction ::= 694 AlgorithmIdentifier {{KDFAlgorithms}} 696 KDFAlgorithms ALGORITHM ::= { 697 kdf2 | kdf3, 698 ... -- implementations may define other methods 699 } 701 * keyLength is the length in bytes of the key-encrypting 702 key, which depends on the underlying symmetric key- 703 wrapping scheme. 704 KeyLength ::= INTEGER (1..MAX) 706 * dem identifies the underlying data encapsulation mechanism. 707 For alignment with ANS X9.44, it MUST be an X9-approved 708 symmetric key-wrapping scheme. (See Note.) However, other 709 symmetric key-wrapping schemes MAY be used with CMS. Please see 710 B.2.2 for the syntax for the AES, Triple-DES, and Camillia Key 711 Wraps. 713 DataEncapsulationMechanism ::= 714 AlgorithmIdentifier {{DEMAlgorithms}} 716 DEMAlgorithms ALGORITHM ::= { 717 X9-SymmetricKeyWrappingSchemes, 718 Camillia-KeyWrappingSchemes, 719 ... -- implementations may define other methods 720 } 722 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 723 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 724 ... -- allows for future expansion 725 } 727 Camillia-KeyWrappingSchemes ALGORITHM ::= { 728 camillia128-Wrap | camillia192-Wrap | camillia256-Wrap 729 } 731 NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt 732 arbitrary data, hence the term "data encapsulation mechanism". The 733 symmetric key-wrapping schemes take the role of data encapsulation 734 mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2 735 allows only three specific data encapsulation mechanisms, not 736 including any of these symmetric key-wrapping schemes. However, the 737 ASN.1 syntax in that document expects that additional algorithms will 738 be allowed. 740 B.2 Selected Underlying Components 742 B.2.1 Key Derivation Functions 744 The object identifier for KDF2 (see [ANS X9.44]) is: 746 id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } 748 The associated parameters identify the underlying hash function. For 749 alignment with ANS X9.44, the hash function MUST be an ASC 750 X9-approved hash function. However, other hash functions MAY be used 751 with CMS. 753 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 755 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 757 KDF2-HashFunctions ALGORITHM ::= { 758 X9-HashFunctions, 759 ... -- implementations may define other methods 760 } 762 X9-HashFunctions ALGORITHM ::= { 763 sha1 | sha224 | sha256 | sha384 | sha512, 764 ... -- allows for future expansion 765 } 767 The object identifier for SHA-1 is 769 id-sha1 OID ::= { 770 iso(1) identified-organization(3) oiw(14) secsig(3) 771 algorithms(2) sha1(26) 772 } 774 The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are 776 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } 777 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 778 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 779 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 781 There has been some confusion over whether the various SHA object 782 identifiers have a NULL parameter, or no associated parameters. As 783 also discussed in [PKCS1], implementations SHOULD generate algorithm 784 identifiers without parameters, and MUST accept algorithm identifiers 785 either without parameters, or with NULL parameters. 787 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be 788 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 789 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 790 sha384 ALGORITHM ::= {{ OID id-sha384 }} -- "" 791 sha512 ALGORITHM ::= {{ OID id-sha512 }} -- "" 793 The object identifier for KDF3 (see [ANS X9.44]) is: 795 id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } 797 The associated parameters identify the underlying hash function. For 798 alignment with the draft ANS X9.44, the hash function MUST be an ASC 799 X9-approved hash function. (See Note.) However, other hash functions 800 MAY be used with CMS. 802 kdf3 ALGORITHM ::= {{ OID id-kdf-kdf3 PARMS KDF3-HashFunction }} 804 KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} 806 KDF3-HashFunctions ALGORITHM ::= { 807 X9-HashFunctions, 808 ... -- implementations may define other methods 809 } 811 B.2.2 Symmetric Key-Wrapping Schemes 813 The object identifiers for the AES Key Wrap depends on the size of 814 the key encrypting key. There are three object identifiers (see 815 [AES-WRAP]): 817 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 818 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 819 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 821 These object identifiers have no associated parameters. 823 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 824 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 825 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 827 The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) 828 is 829 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 830 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 831 smime(16) alg(3) 6 832 } 834 This object identifier has a NULL parameter. 836 tdes-Wrap ALGORITHM ::= 837 {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 839 NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key 840 Wrap are in the process of being approved by ASC X9. 842 The object identifiers for the Camillia Key Wrap depends on the size 843 of the key encrypting key. There are three object identifiers: 845 id-camellia128-Wrap OBJECT IDENTIFIER ::= 847 { iso(1) member-body(2) 392 200011 61 security(1) 848 algorithm(1) key-wrap-algorithm(3) 849 camellia128-wrap(2) } 851 id-camellia192-Wrap OBJECT IDENTIFIER ::= 852 { iso(1) member-body(2) 392 200011 61 security(1) 853 algorithm(1) key-wrap-algorithm(3) 854 camellia192-wrap(3) } 856 id-camellia256-Wrap OBJECT IDENTIFIER ::= 857 { iso(1) member-body(2) 392 200011 61 security(1) 858 algorithm(1) key-wrap-algorithm(3) 859 camellia256-wrap(4) } 861 These object identifiers have no associated parameters. 863 camellia128-Wrap ALGORITHM ::= {{ OID id-camellia128-wrap }} 864 camellia192-Wrap ALGORITHM ::= {{ OID id-camellia192-wrap }} 865 camellia256-Wrap ALGORITHM ::= {{ OID id-camellia256-wrap }} 867 B.3 ASN.1 module 869 CMS-RSA-KEM 870 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 871 pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } [[check]] 873 BEGIN 875 -- EXPORTS ALL 877 -- IMPORTS None 879 -- Useful types and definitions 881 OID ::= OBJECT IDENTIFIER -- alias 883 -- Unless otherwise stated, if an object identifier has associated 884 -- parameters (i.e., the PARMS element is specified), the parameters 885 -- field shall be included in algorithm identifier values. The 886 -- parameters field shall be omitted if and only if the object 887 -- identifier does not have associated parameters (i.e., the PARMS 888 -- element is omitted), unless otherwise stated. 890 ALGORITHM ::= CLASS { 891 &id OBJECT IDENTIFIER UNIQUE, 892 &Type OPTIONAL 893 } 894 WITH SYNTAX { OID &id [PARMS &Type] } 895 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 896 algorithm ALGORITHM.&id( {IOSet} ), 897 parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL 898 } 900 NullParms ::= NULL 902 -- ISO/IEC 18033-2 arc 904 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 906 -- NIST algorithm arc 908 nistAlgorithm OID ::= { 909 joint-iso-itu-t(2) country(16) us(840) organization(1) 910 gov(101) csor(3) nistAlgorithm(4) 911 } 913 -- PKCS #1 arc 915 pkcs-1 OID ::= { 916 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 917 } 919 -- RSA-KEM Key Transport Algorithm, based on Generic Hybrid Cipher 921 id-ac-generic-hybrid OID ::= { 922 is18033-2 asymmetric-cipher(1) generic-hybrid(2) 923 } 925 GenericHybridParameters ::= { 926 kem KeyEncapsulationMechanism, 927 dem DataEncapsulationMechanism 928 } 930 id-kem-rsa OID ::= { 931 is18033-2 key-encapsulation-mechanism(2) rsa(4) 932 } 934 RsaKemParameters ::= { 935 keyDerivationFunction KeyDerivationFunction, 936 keyLength KeyLength 937 } 939 KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} 941 KDFAlgorithms ALGORITHMS ::= { 942 kdf2 | kdf3, 943 ... -- implementations may define other methods 944 } 946 KeyLength ::= INTEGER (1..MAX) 947 DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} 949 DEMAlgorithms ALGORITHM ::= { 950 X9-SymmetricKeyWrappingSchemes, 951 Camillia-KeyWrappingSchemes, 952 ... -- implementations may define other methods 953 } 955 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 956 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 957 ... -- allows for future expansion 958 } 960 Camillia-KeyWrappingSchemes ALGORITHM ::= { 961 camillia128-Wrap | camillia192-Wrap | camillia128-Wrap 962 } 964 -- Key Derivation Functions 966 id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } 968 kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} 970 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} 972 KDF2-HashFunctions ALGORITHM ::= { 973 X9-HashFunctions, 974 ... -- implementations may define other methods 975 } 977 -- id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } 979 kdf3 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF3-HashFunction }} 981 KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} 983 KDF3-HashFunctions ALGORITHM ::= { 984 X9-HashFunctions, 985 ... -- implementations may define other methods 986 } 988 -- Hash Functions 990 X9-HashFunctions ALGORITHM ::= { 991 sha1 | sha224 | sha256 | sha384 | sha512, 992 ... -- allows for future expansion 993 } 995 id-sha1 OID ::= { 996 iso(1) identified-organization(3) oiw(14) secsig(3) 997 algorithms(2) sha1(26) 998 } 999 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha256(4) } 1000 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 1001 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 1002 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 1004 sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NullParms MUST be 1005 sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these 1006 sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs 1007 sha384 ALGORITHM ::= {{ OID id-sha384 }} -- "" 1008 sha512 ALGORITHM ::= {{ OID id-sha512 }} -- "" 1010 -- Symmetric Key-Wrapping Schemes 1012 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 1013 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 1014 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 1016 aes128-Wrap ALGORITHM ::= {{ OID id-aes128-wrap }} 1017 aes192-Wrap ALGORITHM ::= {{ OID id-aes192-wrap }} 1018 aes256-Wrap ALGORITHM ::= {{ OID id-aes256-wrap }} 1020 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 1021 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1022 smime(16) alg(3) 6 1023 } 1025 tdes-Wrap ALGORITHM ::= {{ OID id-alg-CMS3DESwrap PARMS NullParms }} 1027 id-camellia128-Wrap OBJECT IDENTIFIER ::= 1028 { iso(1) member-body(2) 392 200011 61 security(1) 1029 algorithm(1) key-wrap-algorithm(3) 1030 camellia128-wrap(2) } 1032 id-camellia192-Wrap OBJECT IDENTIFIER ::= 1033 { iso(1) member-body(2) 392 200011 61 security(1) 1034 algorithm(1) key-wrap-algorithm(3) 1035 camellia192-wrap(3) } 1037 id-camellia256-Wrap OBJECT IDENTIFIER ::= 1038 { iso(1) member-body(2) 392 200011 61 security(1) 1039 algorithm(1) key-wrap-algorithm(3) 1040 camellia256-wrap(4) } 1042 camellia128-Wrap ALGORITHM ::= {{ OID id-camellia128-wrap }} 1043 camellia192-Wrap ALGORITHM ::= {{ OID id-camellia192-wrap }} 1044 camellia256-Wrap ALGORITHM ::= {{ OID id-camellia256-wrap }} 1046 B.4 Examples 1048 As an example, if the key derivation function is KDF2 based on 1049 SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap 1050 with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key 1051 Transport Algorithm will have the following value: 1053 SEQUENCE { 1054 id-ac-generic-hybrid, -- generic cipher 1055 SEQUENCE { -- GenericHybridParameters 1056 SEQUENCE { -- key encapsulation mechanism 1057 id-kem-rsa, -- RSA-KEM 1058 SEQUENCE { -- RsaKemParameters 1059 SEQUENCE { -- key derivation function 1060 id-kdf-kdf2, -- KDF2 1061 SEQUENCE { -- KDF2-HashFunction 1062 id-sha256 -- SHA-256; no parameters (preferred) 1063 }, 1064 16 -- KEK length in bytes 1065 }, 1066 SEQUENCE { -- data encapsulation mechanism 1067 id-aes128-Wrap -- AES-128 Wrap; no parameters 1068 } 1069 } 1070 } 1072 This AlgorithmIdentifier value has the following DER encoding: 1074 30 4f 1075 06 07 28 81 8c 71 02 01 02 -- id-ac-generic-hybrid 1076 30 44 1077 30 25 1078 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 1079 30 1a 1080 30 16 1081 06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 1082 30 0b 1083 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 1084 02 10 -- 16 bytes 1085 30 0b 1086 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 1088 The DER encodings for other typical sets of underlying components are 1089 as follows: 1091 * KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK 1093 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 1094 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 1095 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 1096 02 02 02 18 30 0b 06 09 60 86 48 01 65 03 04 01 1097 19 1099 * KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK 1101 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 1102 07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 1103 8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 1104 02 03 02 20 30 0b 06 09 60 86 48 01 65 03 04 01 1105 2d 1107 * KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK 1108 (two-key triple-DES) 1110 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 1111 07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81 1112 8c 71 02 05 02 30 07 06 05 2b 0e 03 02 1a 02 10 1113 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 1114 00 1116 Full Copyright Statement 1118 Copyright (C) The IETF Trust (2007). 1120 This document and translations of it may be copied and furnished to 1121 others, and derivative works that comment on or otherwise explain it 1122 or assist in its implementation may be prepared, copied, published 1123 and distributed, in whole or in part, without restriction of any 1124 kind, provided that the above copyright notice and this paragraph 1125 are included on all such copies and derivative works. However, this 1126 document itself may not be modified in any way, such as by removing 1127 the copyright notice or references to the Internet Society or other 1128 Internet organizations, except as needed for the purpose of 1129 developing Internet standards in which case the procedures for 1130 copyrights defined in the Internet Standards process must be 1131 followed, or as required to translate it into languages other than 1132 English. 1134 The limited permissions granted above are perpetual and will not be 1135 revoked by the Internet Society or its successors or assigns. 1137 Disclaimer Statement 1139 This document and the information contained herein are provided on an 1140 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1141 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1142 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1143 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1144 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1145 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.