idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '...mpliant software MUST meet the require...' RFC 2119 keyword, line 113: '...t-encryption key MUST be randomly gene...' RFC 2119 keyword, line 120: '...ds of the EnvelopedData syntax MUST be...' RFC 2119 keyword, line 124: '...elopedData version MUST be 0, 2, or 3....' RFC 2119 keyword, line 127: '... However, this field MAY be present to...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 2002) is 7956 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? 'RSALABS' on line 49 looks like a reference -- Missing reference section? 'CRYPTO98' on line 49 looks like a reference -- Missing reference section? 'MMA' on line 58 looks like a reference -- Missing reference section? 'CMS' on line 110 looks like a reference -- Missing reference section? 'SSL' on line 66 looks like a reference -- Missing reference section? 'TLS' on line 67 looks like a reference -- Missing reference section? 'PROFILE' on line 88 looks like a reference -- Missing reference section? 'STDWORDS' on line 97 looks like a reference -- Missing reference section? '3DES' on line 169 looks like a reference -- Missing reference section? '0' on line 467 looks like a reference -- Missing reference section? '1' on line 468 looks like a reference -- Missing reference section? '2' on line 469 looks like a reference -- Missing reference section? 'SHA1' on line 231 looks like a reference -- Missing reference section? 'MSG' on line 259 looks like a reference -- Missing reference section? 'RANDOM' on line 377 looks like a reference -- Missing reference section? 'SHA2' on line 400 looks like a reference -- Missing reference section? 'NISTGUIDE' on line 417 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft RSA Laboratories 4 expires in six months July 2002 6 Use of the RSAES-OAEP Key Transport Algorithm in CMS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.htmlCopyright Notice 28 Copyright (C) The Internet Society (2002). All Rights Reserved. 30 Abstract 32 This document describes the use of the RSAES-OAEP key transport 33 method of key management within the Cryptographic Message Syntax 34 (CMS). 36 1 Introduction 38 This draft is being discussed on the "ietf-smime" mailing list. To 39 join the list, send a message to with 40 the single word "subscribe" in the body of the message. Also, there 41 is a Web site for the mailing list at . 44 PKCS #1 Version 1.5 [PKCS#1v1.5] specifies a widely deployed variant 45 of the RSA key transport algorithm. PKCS #1 Version 1.5 key 46 transport is vulnerable to adaptive chosen ciphertext attacks, 47 especially when it is used to for key management in interactive 48 applications. This attack is often referred to as the "Million 49 Message Attack," and it explained in [RSALABS] and [CRYPTO98]. 50 Exploitation of this vulnerability, which reveals the result of a 51 particular RSA decryption, requires access to an oracle which will 52 respond to hundreds of thousands of ciphertexts, which are 53 constructed adaptively in response to previously received replies 54 that provide information on the successes or failures of attempted 55 decryption operations. 57 The attack is significantly less feasible in store-and-forward 58 environments, such as S/MIME. RFC 3218 [MMA] discussed the 59 countermeasures to this attack that are available when PKCS #1 60 Version 1.5 key transport is used in conjunction with the 61 Cryptographic Message Syntax (CMS) [CMS]. 63 When PKCS #1 Version 1.5 key transport is applied as an intermediate 64 encryption layer within an interactive request-response 65 communications environment, exploitation could be more feasible. 66 However, Secure Sockets Layer (SSL) [SSL] and Transport Layer 67 Security (TLS) [TLS] protocol implementations could include 68 countermeasures that detect and prevent the Million Message Attack 69 and other chosen-ciphertext attacks. These countermeasures are 70 performed within the protocol level. 72 In the interest of long-term security assurance, it is prudent to 73 adopt an improved cryptographic technique rather than embedding 74 countermeasures within protocols. To this end, an updated version of 75 PKCS #1 has been published. PKCS #1 Version 2.0 [PKCS#1v2.0] 76 supersedes RFC 2313. It preserves support for the PKCS #1 Version 77 1.5 encryption padding format, and it also defines a new one. To 78 resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 79 Version 2.0 specifies and recommends use of Optimal Asymmetric 80 Encryption Padding (OAEP) for RSA key transport. 82 This document specifies the use of RSAES-OAEP key transport algorithm 83 in the CMS. The CMS can be used in either a store-and-forward or an 84 interactive request-response environment. 86 The CMS supports variety of architectures for certificate-based key 87 management, particularly the one defined by the PKIX working group 88 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 89 same RSA public key information. Thus, a certified RSA public key 90 may be used with either RSA key transport technique. 92 The CMS uses ASN.1 [X.208-88], the Basic Encoding Rules (BER) 93 [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88]. 95 Throughout this document, when the terms "MUST," "MUST NOT," 96 "SHOULD," and "MAY" are used in capital letters, their use conforms 97 to the definitions in RFC 2119 [STDWORDS]. These key word 98 definitions help make the intent of standards documents as clear as 99 possible. These key words are used in this document to help 100 implementers achieve interoperability. 102 2 Enveloped-data Conventions 104 The CMS enveloped-data content type consists of an encrypted content 105 and wrapped content-encryption keys for one or more recipients. The 106 RSAES-OAEP key transport algorithm is used to wrap the content- 107 encryption key for one recipient. 109 Compliant software MUST meet the requirements for constructing an 110 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 111 data Content Type". 113 A content-encryption key MUST be randomly generated for each instance 114 of an enveloped-data content type. The content-encryption key is 115 used to encipher the content. 117 2.1 EnvelopedData Fields 119 The enveloped-data content type is ASN.1 encoded using the 120 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 121 populated as described in this section when RSAES-OAEP key transport 122 is employed for one or more recipients. 124 The EnvelopedData version MUST be 0, 2, or 3. 126 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 127 key transport algorithm. However, this field MAY be present to 128 support recipients using other key management algorithms. 130 The EnvelopedData recipientInfos CHOICE MUST be 131 KeyTransRecipientInfo. See section 2.2 for further discussion of 132 KeyTransRecipientInfo. 134 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 135 field MUST be a symmetric encryption algorithm identifier. 137 The EnvelopedData unprotectedAttrs MAY be present. 139 2.2 KeyTransRecipientInfo Fields 141 The fields of the KeyTransRecipientInfo syntax MUST be populated as 142 described in this section when RSAES-OAEP key transport is employed 143 for one or more recipients. 145 The KeyTransRecipientInfo version MUST be 0 or 2. If the 146 RecipientIdentifier uses the issuerAndSerialNumber alternative, then 147 the version MUST be 0. If the RecipientIdentifier uses the 148 subjectKeyIdentifier alternative, then the version MUST be 2. 150 The KeyTransRecipientInfo RecipientIdentifier provides two 151 alternatives for specifying the recipient's certificate, and thereby 152 the recipient's public key. The recipient's certificate MUST contain 153 a RSA public key. The content-encryption key is encrypted with the 154 recipient's RSA public key. The issuerAndSerialNumber alternative 155 identifies the recipient's certificate by the issuer's distinguished 156 name and the certificate serial number; the subjectKeyIdentifier 157 identifies the recipient's certificate by the X.509 158 subjectKeyIdentifier extension value. 160 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies use of the 161 RSAES-OAEP algorithm, and its associated parameters, to encrypt the 162 content-encryption key for the recipient. The key-encryption process 163 is described in [PKCS#1v2.0]. See section 3 of this document for the 164 algorithm identifier and the parameter syntax. 166 The KeyTransRecipientInfo encryptedKey is the result of encrypting 167 the content-encryption key in the recipient's RSA public key using 168 the RSAES-OAEP algorithm. The RSA public key MUST be at least 1024 169 bits in length. When using a Triple-DES [3DES] content-encryption 170 key, implementations MUST adjust the parity bits to ensure odd parity 171 for each octet of each DES key comprising the Triple-DES key prior to 172 RSAES-OAEP encryption. 174 3 RSAES-OAEP Algorithm Identifiers and Parameters 176 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 177 defined in RFC 2437 [PKCS#1v2.0], where the message to be encrypted 178 is the content-encryption key. The algorithm identifier for RSAES- 179 OAEP is: 181 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 182 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 184 The AlgorithmIdentifier parameters field MUST be present, and the 185 parameters field MUST contain RSAES-OAEP-params. RSAES-OAEP-params 186 has the following syntax: 188 RSAES-OAEP-params ::= SEQUENCE { 189 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 190 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 191 pSourceFunc [2] AlgorithmIdentifier DEFAULT 192 pSpecifiedEmptyIdentifier } 194 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 196 mgf1SHA1Identifier AlgorithmIdentifier ::= 197 { id-mgf1, sha1Identifier } 199 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 200 { id-pSpecified, nullOctetString } 202 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 204 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 205 identified-organization(3) oiw(14) 206 secsig(3) algorithms(2) 26 } 208 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 209 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) } 211 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 213 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 215 The fields within RSAES-OAEP-params have the following meanings: 217 hashFunc identifies the one-way hash function. Implementations 218 MUST support SHA-1 [SHA1], and implementations MAY support other 219 one-way hash functions in addition to SHA-1. The SHA-1 algorithm 220 identifier is comprised of the id-sha1 object identifier and a 221 parameter of NULL. Implementations that perform encryption MUST 222 omit the hashFunc field when SHA-1 is used, indicating that the 223 default algorithm was used. Implementations that perform 224 decryption MUST recognize both the id-sha1 object identifier and 225 an absent hashFunc field as an indication that SHA-1 was used. 227 maskGenFunc identifies the mask generation function. 228 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 229 one-way hash function, and it is identified in the parameter field 230 of the MFG1 algorithm identifier. Implementations MUST support 231 SHA-1 [SHA1], and implementations MAY support other one-way hash 232 functions. The MFG1 algorithm identifier is comprised of the id- 233 mgf1 object identifier and a parameter that contains the algorithm 234 identifier of the one-way hash function employed with MFG1. The 235 SHA-1 algorithm identifier is comprised of the id-sha1 object 236 identifier and a parameter of NULL. Implementations that perform 237 encryption MUST omit the maskGenFunc field when MFG1 with SHA-1 is 238 used, indicating that the default algorithm was used. 239 Implementations that perform decryption MUST recognize both the 240 id-mgf1 and id-sha1 object identifiers as well as an absent 241 maskGenFunc field as an indication that MFG1 with SHA-1 was used. 243 pSourceFunc identifies the source (and possibly the value) of the 244 encoding parameters, commonly called P. Implementations MUST 245 represent P by an algorithm identifier, id-pSpecified, indicating 246 that P is explicitly provided as an OCTET STRING in the 247 parameters. The default value for P is an empty string. In this 248 case, pHash in EME-OAEP contains the hash of a zero length string. 249 Implementations MUST support a zero length P value. 250 Implementations that perform encryption MUST omit the pSourceFunc 251 field when a zero length P value is used, indicating that the 252 default value was used. Implementations that perform decryption 253 MUST recognize both the id-pSpecified object identifier and an 254 absent pSourceFunc field as an indication that a zero length P 255 value was used. 257 4 SMIMECapabilities Attribute Conventions 259 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 260 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 261 used to specify a partial list of algorithms that the software 262 announcing the SMIMECapabilities can support. When constructing a 263 signedData object, compliant software MAY include the 264 SMIMECapabilities signed attribute announcing that it supports the 265 RSAES-OAEP algorithm. 267 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 268 id-RSAES-OAEP object identifier in the capabilityID field and MUST 269 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 270 field. 272 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 273 { id-RSAES-OAEP, 274 { sha1Identifier, 275 mgf1SHA1Identifier, 276 pSpecifiedEmptyIdentifier } } 278 When all of the default settings are selected, the SMIMECapability 279 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as the following 280 hexadecimal string: 282 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 284 5 References 286 This section provides normative and informative references. 288 5.1 Normative References 290 3DES American National Standards Institute. ANSI X9.52-1998, 291 Triple Data Encryption Algorithm Modes of Operation. 1998. 293 CMS Housley, R. Cryptographic Message Syntax. RFC . 294 . 296 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 297 RFC 2633. June 1999. 299 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 300 RFC 2437. October 1998. 302 PROFILE Housley, R., W. Polk, W. Ford, and D. Solo. Internet 303 X.509 Public Key Infrastructure: Certificate and 304 Certificate Revocation List (CRL) Profile. RFC 3280. 305 April 2002. 307 SHA1 National Institute of Standards and Technology. 308 FIPS Pub 180-1: "Secure Hash Standard." April 1995. 310 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 311 Requirement Levels. BCP 14, RFC 2119. March 1997. 313 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 314 Syntax Notation One (ASN.1). 1988. 316 X.209-88 CCITT. Recommendation X.209: Specification of Basic 317 Encoding Rules for Abstract Syntax Notation One 318 (ASN.1). 1988. 320 X.509-88 CCITT. Recommendation X.509: The Directory - 321 Authentication Framework. 1988. 323 5.2 Informative References 325 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 326 Protocols Based on the RSA Encryption Standard PKCS #1," 327 in H. Krawczyk (editor), Advances in Cryptology - 328 CRYPTO '98 Proceedings, Lecture Notes in Computer 329 Science 1462 (1998), Springer-Verlag, pp. 1-12. 331 MMA Rescorla, E. Preventing the Million Message Attack on 332 Cryptographic Message Syntax. RFC 3218. January 2002. 334 NISTGUIDE National Institute of Standards and Technology. 335 Second Draft: "Key Management Guideline, Part 1: 336 General Guidance." June 2002. 337 [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 339 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 340 RFC 2313. March 1998. 342 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 343 Recommendations for Security. RFC 1750. December 1994. 345 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 346 Recent Results on PKCS #1: RSA Encryption Standard. 347 RSA Laboratories' Bulletin No. 7, June 26, 1998. 348 [http://www.rsasecurity.com/rsalabs/bulletins] 350 SHA2 National Institute of Standards and Technology. 351 Draft FIPS Pub 180-2: "Specifications for the Secure 352 Hash Standard." May 2001. 353 [http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf] 355 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 356 Version 3.0. Netscape Communications. November 1996. 357 [http://wp.netscape.com/eng/ssl3/draft302.txt] 359 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 360 RFC 2246. January 1999. 362 6 Security Considerations 364 Implementations must protect the RSA private key and the content- 365 encryption key. Compromise of the RSA private key may result in the 366 disclosure of all messages protected with that key. Compromise of 367 the content-encryption key may result in disclosure of the associated 368 encrypted content. 370 The generation of RSA public/private key pairs relies on a random 371 numbers. The use of inadequate pseudo-random number generators 372 (PRNGs) to generate cryptographic keys can result in little or no 373 security. An attacker may find it much easier to reproduce the PRNG 374 environment that produced the keys, searching the resulting small set 375 of possibilities, rather than brute force searching the whole key 376 space. The generation of quality random numbers is difficult. RFC 377 1750 [RANDOM] offers important guidance in this area. 379 Generally, good cryptographic practice employs a given RSA key pair 380 in only one scheme. This practice avoids the risk that vulnerability 381 in one scheme may compromise the security of the other, and may be 382 essential to maintain provable security. While PKCS #1 Version 1.5 383 [PKCS#1v1.5] has been employed for both key transport and digital 384 signature without any known bad interactions, such a combined use of 385 an RSA key pair is not recommended in the future. Therefore, an RSA 386 key pair used for RSAES-OAEP key transport should not also be used 387 for other purposes. 389 This specification requires implementation to support the SHA-1 one- 390 way hash function for interoperability, but support for other one-way 391 hash function is permitted. At the time of this writing, the best 392 (known) collision attacks against SHA-1 are generic attacks with 393 complexity 2^80, where 80 is one-half the bit length of the hash 394 value. When a one-way hash function is used with a digital signature 395 scheme, a collision attack is easily translated into a signature 396 forgery. Therefore, the use of SHA-1 in a digital signature scheme 397 provides a security level of no more than 80 bits. If a greater 398 level of security is desired, then a secure one-way hash function 399 with a longer hash value is needed. SHA-256, SHA-384, and SHA-512 400 are likely candidates [SHA2]. 402 The metrics for choosing a one-way hash function for use in digital 403 signatures do not directly apply to the RSAES-OAEP key transport 404 algorithm, since a collision attack on the one-way hash function does 405 not directly translate into an attack on the key transport algorithm, 406 unless the encoding parameters P varies (in which case a collision 407 the hash value for different encoding parameters might be exploited). 408 Nevertheless, for consistency with the practice for digital signature 409 schemes, and in case the encoding parameters P is not the empty 410 string, it is recommended that the same rule of thumb be applied to 411 selection of a one-way hash function for use with RSAES-OAEP. That 412 is, the one-way hash function should be selected so that the bit 413 length of the hash value is at least twice as long as the desired 414 security level in bits. 416 A 1024-bit RSA public key and SHA-1 both provide a security level of 417 about 80 bits. In [NISTGUIDE], the National Institute of Standards 418 and Technology suggests that a security level of 80 bits is adequate 419 for most applications until 2015. If a security level greater than 420 80 bits is needed, then a longer RSA public key and a secure one-way 421 hash function with a longer hash value are needed. Again, SHA-256, 422 SHA-384, and SHA-512 are likely candidates for such a one-way hash 423 function. For this reason, the algorithm identifiers for these one- 424 way hash functions are included in the ASN.1 module in Appendix A. 426 7 Acknowledgments 428 This document is the result of contributions from many professionals. 429 I appreciate the hard work of all members of the IETF S/MIME Working 430 Group. Further, I extend a special thanks to Burt Kaliski, Jakob 431 Jonsson, and Francois Rousseau. 433 8 Author Address 435 Russell Housley 436 RSA Laboratories 437 918 Spring Knoll Drive 438 Herndon, VA 20170 439 USA 441 rhousley@rsasecurity.com 443 Appendix A ASN.1 Module 445 CMS-RSAES-OAEP 446 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 447 pkcs-9(9) smime(16) modules(0) cms-rsaes-oaep(20) } 449 DEFINITIONS IMPLICIT TAGS ::= 450 BEGIN 452 -- EXPORTS ALL -- 454 IMPORTS 455 AlgorithmIdentifier 456 FROM PKIX1Explicit88 -- RFC 3280 457 { iso(1) identified-organization(3) dod(6) internet(1) 458 security(5) mechanisms(5) pkix(7) id-mod(0) 459 id-pkix1-explicit(18) }; 461 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 462 rsadsi(113549) pkcs(1) pkcs-1(1) } 464 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 466 RSAES-OAEP-params ::= SEQUENCE { 467 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 468 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 469 pSourceFunc [2] AlgorithmIdentifier DEFAULT 470 pSpecifiedEmptyIdentifier } 472 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 473 sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 475 sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } 477 sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 479 mgf1SHA1Identifier AlgorithmIdentifier ::= 480 { id-mgf1, sha1Identifier } 482 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 483 { id-pSpecified, nullOctetString } 485 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 487 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 488 identified-organization(3) oiw(14) 489 secsig(3) algorithms(2) 26 } 491 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 492 country(16) us(840) organization(1) gov(101) 493 csor(3) nistalgorithm(4) hashalgs(2) 1 } 495 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 496 country(16) us(840) organization(1) gov(101) 497 csor(3) nistalgorithm(4) hashalgs(2) 2 } 499 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 500 country(16) us(840) organization(1) gov(101) 501 csor(3) nistalgorithm(4) hashalgs(2) 3 } 503 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 505 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 507 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 508 { id-RSAES-OAEP, 509 { sha1Identifier, 510 mgf1SHA1Identifier, 511 pSpecifiedEmptyIdentifier } } 513 END 515 Full Copyright Statement 517 Copyright (C) The Internet Society (2002). All Rights Reserved. 519 This document and translations of it may be copied and furnished to 520 others, and derivative works that comment on or otherwise explain it 521 or assist in its implementation may be prepared, copied, published 522 and distributed, in whole or in part, without restriction of any 523 kind, provided that the above copyright notice and this paragraph are 524 included on all such copies and derivative works. In addition, the 525 ASN.1 module presented in Appendix A may be used in whole or in part 526 without inclusion of the copyright notice. However, this document 527 itself may not be modified in any way, such as by removing the 528 copyright notice or references to the Internet Society or other 529 Internet organizations, except as needed for the purpose of 530 developing Internet standards in which case the procedures for 531 copyrights defined in the Internet Standards process shall be 532 followed, or as required to translate it into languages other than 533 English. 535 The limited permissions granted above are perpetual and will not be 536 revoked by the Internet Society or its successors or assigns. This 537 document and the information contained herein is provided on an "AS 538 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 539 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 540 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 541 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 542 OR FITNESS FOR A PARTICULAR PURPOSE.