idnits 2.17.1 draft-ietf-pkix-rsa-pkalgs-03.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == 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 (March 2004) is 7309 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: 'SHA-224' is mentioned on line 216, but not defined -- Looks like a reference, but probably isn't: '0' on line 917 -- Looks like a reference, but probably isn't: '1' on line 919 -- Looks like a reference, but probably isn't: '2' on line 921 -- Looks like a reference, but probably isn't: '3' on line 906 == Unused Reference: 'SHA224' is defined on line 946, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' == Outdated reference: A later version (-01) exists of draft-ietf-pkix-sha224-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-sha224 (ref. 'SHA224') -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group J. Schaad (Soaring Hawk Consulting) 2 Internet Draft B. Kaliski (RSA Laboratories) 3 R. Housley (Vigil Security) 4 expires September 2004 March 2004 6 Additional Algorithms and Identifiers for RSA Cryptography 7 for use in the Internet X.509 Public Key Infrastructure 8 Certificate and Certificate Revocation List (CRL) Profile 9 11 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Drafts Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document supplements RFC 3279. It describes the conventions 32 for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 33 transport algorithm and additional one-way hash functions with the 34 PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 35 Key Infrastructure (PKI). Encoding formats, algorithm identifiers, 36 and parameter formats are specified. 38 Table of Contents 40 1 Introduction.......................................................2 41 1.1 Terminology....................................................2 42 1.2 RSA Public Keys................................................2 43 2 Common Functions...................................................5 44 2.1 One-way Hash Functions.........................................5 45 2.2 Mask Generation Functions......................................6 46 3 RSASSA-PSS Signature Algorithm.....................................7 47 3.1 RSASSA-PSS Public Keys.........................................7 48 3.2 RSASSA-PSS Signature Values....................................9 49 3.3 RSASSA-PSS Signature Parameter Validation......................9 51 4 RSAES-OAEP Key Transport Algorithm................................10 52 4.1 RSAES-OAEP Public Keys........................................10 53 5 PKCS #1 Version 1.5 Signature Algorithm...........................12 54 6 ASN.1 Module......................................................13 55 7 References........................................................19 56 7.1 Normative References..........................................19 57 7.2 Informative References........................................19 58 8 Security Considerations...........................................20 59 10 Author Addresses.................................................22 60 11 Full Copyright Statement.........................................22 62 1 Introduction 64 This document supplements RFC 3279 [PKALGS]. This document 65 describes the conventions for using the RSASSA-PSS signature 66 algorithm and the RSAES-OAEP key transport algorithm in the Internet 67 X.509 Public Key Infrastructure (PKI) [PROFILE]. Both of these RSA- 68 based algorithms are specified in [P1v2.1]. The algorithm 69 identifiers and associated parameters for subject public keys that 70 employ either of these algorithms are specified, and the encoding 71 format for RSASSA-PSS signatures is specified. Also, the algorithm 72 identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 73 one-way hash functions with the PKCS #1 version 1.5 signature 74 algorithm [P1v1.5] are specified. 76 This specification supplements RFC 3280 [PROFILE], which profiles 77 the X.509 Certificates and Certificate Revocation Lists (CRLs) for 78 use in the Internet. This specification extends the list of 79 algorithms discussed in RFC 3279 [PKALGS]. The X.509 Certificate 80 and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules 81 (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509- 82 88]. 84 This specification defines the contents of the signatureAlgorithm, 85 signatureValue, signature, and subjectPublicKeyInfo fields within 86 Internet X.509 certificates and CRLs. For each algorithm, the 87 appropriate alternatives for the keyUsage extension are provided. 89 1.1 Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [STDWORDS]. 95 1.2 RSA Public Keys 97 RFC 3280 [PROFILE] specifies the profile for using X.509 98 Certificates in Internet applications. When a RSA public key will 100 be used for RSASSA-PSS digital signatures or RSAES-OAEP key 101 transport, the conventions specified in this section augment RFC 102 3280. 104 Traditionally, the rsaEncryption object identifier is used to 105 identify RSA public keys. However, to implement all of the 106 recommendations described in the Security Considerations section of 107 this document (see section 8), the certificate user needs to be able 108 to determine the form of digital signature or key transport that the 109 RSA private key owner associates with the public key. 111 The rsaEncryption object identifier continues to identify the 112 subject public key when the RSA private key owner does not wish to 113 limit the use of the public key exclusively to either RSASSA-PSS or 114 RSAES-OAEP. In this case, the rsaEncryption object identifier MUST 115 be used in the algorithm field within the subject public key 116 information, and the parameters field MUST contain NULL. 118 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 120 Further discussion of the conventions associated with use of the 121 rsaEncryption object identifier can be found in RFC 3279 (see 122 [PKALGS], section 2.3.1). 124 When the RSA private key owner wishes to limit the use of the public 125 key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object 126 identifier MUST be used in the algorithm field within the subject 127 public key information, and, if present, the parameters field MUST 128 contain RSASSA-PSS-params. The id-RSASSA-PSS object identifier 129 value and the RSASSA-PSS-params syntax are fully described in 130 section 3 of this document. 132 When the RSA private key owner wishes to limit the use of the public 133 key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object 134 identifier MUST be used in the algorithm field within the subject 135 public key information, and, if present, the parameters field MUST 136 contain RSAES-OAEP-params. The id-RSAES-OAEP object identifier 137 value and the RSAES-OAEP-params syntax are fully described in 138 section 4 of this document. 140 Note: It is not possible to restrict the use of a key to only just 141 two of the algorithms (i.e. RSASSA-PSS and RSAES-OAEP) in this 142 document. 144 Regardless of the object identifier used, the RSA public key is 145 encoded in the same manner in the subject public key information. 146 The RSA public key MUST be encoded using the type RSAPublicKey type: 148 RSAPublicKey ::= SEQUENCE { 149 modulus INTEGER, -- n 150 publicExponent INTEGER } -- e 152 Here, the modulus is the modulus n, and publicExponent is the public 153 exponent e. The DER encoded RSAPublicKey is carried in the 154 subjectPublicKey BIT STRING within the subject public key 155 information. 157 The intended application for the key MAY be indicated in the key 158 usage certificate extension (see [PROFILE], section 4.2.1.3). 160 If the keyUsage extension is present in an end entity certificate 161 that conveys an RSA public key with the id-RSASSA-PSS object 162 identifier, then the key usage extension MUST contain one or both of 163 the following values: 165 nonRepudiation; and 166 digitalSignature. 168 If the keyUsage extension is present in a certification authority 169 certificate that conveys an RSA public key with the id-RSASSA-PSS 170 object identifier, then the key usage extension MUST contain one or 171 more of the following values: 173 nonRepudiation; 174 digitalSignature; 175 keyCertSign; and 176 cRLSign. 178 When a certificate that conveys an RSA public key with the id- 179 RSASSA-PSS object identifier, the certificate user MUST only use the 180 certified RSA public key for RSASSA-PSS operations, and, if RSASSA- 181 PSS-params is present, the certificate user MUST perform those 182 operations using the one-way hash function, mask generation 183 function, and trailer field identified in the subject public key 184 algorithm identifier parameters within the certificate. 186 If the keyUsage extension is present in a certificate that conveys 187 an RSA public key with the id-RSAES-OAEP object identifier, then the 188 key usage extension MUST contain only the following values: 190 keyEncipherment; and 191 dataEncipherment. 193 However, both keyEncipherment and dataEncipherment SHOULD NOT be 194 present. 196 When a certificate that conveys an RSA public key with the id-RSAES- 197 OAEP object identifier, the certificate user MUST only use the 198 certified RSA public key for RSAES-OAEP operations, and, if RSAES- 199 OAEP-params is present, the certificate user MUST perform those 200 operations using the one-way hash function and mask generation 202 function identified in the subject public key algorithm identifier 203 parameters within the certificate. 205 2 Common Functions 207 The RSASSA-PSS signature algorithm and the RSAES-OAEP key transport 208 algorithm make use of one-way hash functions and mask generation 209 functions. 211 2.1 One-way Hash Functions 213 PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions 214 for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP 215 key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 216 [SHA2]. This document adds additional support for SHA-224 [SHA-224] 217 with both the RSASSA-PSS and the RSAES-OAEP algorithms. While 218 support for additional one-way hash functions could be added in the 219 future, no other one-way hash functions are supported by this 220 specification. 222 These one-way hash functions are identified by the following object 223 identifiers: 225 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 226 identified-organization(3) oiw(14) 227 secsig(3) algorithms(2) 26 } 228 id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) 229 country(16) us(840) organization(1) gov(101) 230 csor(3) nistalgorithm(4) hashalgs(2) 4 } 231 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 232 country(16) us(840) organization(1) gov(101) 233 csor(3) nistalgorithm(4) hashalgs(2) 1 } 234 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 235 country(16) us(840) organization(1) gov(101) 236 csor(3) nistalgorithm(4) hashalgs(2) 2 } 237 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 238 country(16) us(840) organization(1) gov(101) 239 csor(3) nistalgorithm(4) hashalgs(2) 3 } 241 There are two possible encodings for the AlgorithmIdentifier 242 parameters field associated with these object identifiers. The two 243 alternatives arise from the fact that when the 1988 syntax for 244 AlgorithmIdentifier was translated into the 1997 syntax the OPTIONAL 245 associated with the algorithm identifier parameters got lost. Later 246 the OPTIONAL was recovered via a defect report, but by then many 247 people thought that algorithm parameters were mandatory. Because of 248 this history some implementations encode parameters as a NULL 249 element and others omit them entirely. The correct encoding is to 250 omit the parameters field; however, at the time that RSASSA-PSS and 252 RSAES-OAEP were defined it was done using the NULL parameters rather 253 than absent parameters. 255 All implementations MUST accept both NULL and absent parameters as 256 legal and equivalent encodings. 258 To be clear, the following algorithm identifiers are used when a 259 NULL parameter MUST be present: 261 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 263 sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL } 264 sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 265 sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } 266 sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 268 2.2 Mask Generation Functions 270 One mask generation function is used with the RSASSA-PSS signature 271 algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1]. 272 No other mask generation functions are supported by this 273 specification. 275 MGF1 is identified by the following object identifier: 277 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 279 The parameters field associated with id-mgf1 MUST have a 280 hashAlgorithm value, which identifies the hash function being used 281 with MGF1. This value MUST be sha1Identifier, sha224Identifier, 282 sha256Identifier, sha384Identifier, or sha512Identifier, as 283 specified in section 2.1. Implementations MUST support the default 284 value, sha1Identifier, and implementations MAY support the other 285 four values. 287 The following algorithm identifiers have been assigned for each of 288 these alternatives: 290 mgf1SHA1Identifier AlgorithmIdentifier ::= 291 { id-mgf1, sha1Identifier } 292 mgf1SHA224Identifier AlgorithmIdentifier ::= 293 { id-mgf1, sha224Identifier } 294 mgf1SHA256Identifier AlgorithmIdentifier ::= 295 { id-mgf1, sha256Identifier } 296 mgf1SHA384Identifier AlgorithmIdentifier ::= 297 { id-mgf1, sha384Identifier } 298 mgf1SHA512Identifier AlgorithmIdentifier ::= 299 { id-mgf1, sha512Identifier } 301 3 RSASSA-PSS Signature Algorithm 303 This section describes the conventions for using the RSASSA-PSS 304 signature algorithm with the Internet X.509 certificate and CRL 305 profile [PROFILE]. The RSASSA-PSS signature algorithm is specified 306 in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions 307 discussed in section 2.1 and the one mask generation function 308 discussed in section 2.2 can be used with RSASSA-PSS. 310 CAs that issue certificates with the id-RSASSA-PSS algorithm 311 identifier SHOULD require that the parameters be present in the 312 publicKeyAlgorithms field if the cA boolean flag is set in the basic 313 constraints extension. CAs MAY require that the parameters be 314 present in the publicKeyAlgorithms field for end-entity 315 certificates. 317 CAs that use the RSASSA-PSS algorithm for signing certificates, 318 SHOULD have RSASSA-PSS-params the parameters present in their own 319 certificates. CAs that use the RSASSA-PSS algorithm for signing, 320 certificates and CRLs MUST include RSASSA-PSS-params the parameters 321 in the signature algorithm field of the TBSCertificate and 322 TBSCertList structures. 324 Entities that validate RSASSA-PSS signatures MUST have support for 325 SHA-1. They MAY also support the other hashing algorithms in 326 section 2.1. 328 The data to be signed (e.g., the one-way hash function output value) 329 is formatted for the signature algorithm to be used. Then, a 330 private key operation (e.g., RSA encryption) is performed to 331 generate the signature value. This signature value is then ASN.1 332 encoded as a BIT STRING and included in the Certificate or 333 CertificateList in the signature field. Section 3.2 specifies the 334 format of RSASSA-PSS signature values. 336 3.1 RSASSA-PSS Public Keys 338 When RSASSA-PSS is used in an AlgorithmIdentifier,the parameters 339 MUST employ the RSASSA-PSS-params syntax. The parameters may be 340 either absent or present when used as subject public key 341 information. The parameters MUST be present when used in the 342 algorithm identifier associated with for a signature value. 344 When signing, it is RECOMMENDED that, except for saltLength, the 345 parameters remain fixed for all usages of a given RSA key pair. 347 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 349 RSASSA-PSS-params ::= SEQUENCE { 350 hashAlgorithm [0] HashAlgorithm DEFAULT 351 sha1Identifier, 353 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT 354 mgf1SHA1Identifier, 355 saltLength [2] INTEGER DEFAULT 20, 356 trailerField [3] INTEGER DEFAULT 1 } 358 The fields of type RSASSA-PSS-params have the following meanings: 360 hashAlgorithm 362 The hashAlgorithm field identifies the hash function. It MUST 363 be one of the algorithm identifiers listed in section 2.1, and 364 the default hash function is SHA-1. Implementations MUST 365 support SHA-1, and implementations MAY support other one-way 366 hash functions listed in section 2.1. Implementations that 367 perform signature generation MUST omit the hashAlgorithm field 368 when SHA-1 is used, indicating that the default algorithm was 369 used. Implementations that perform signature validation MUST 370 recognize both the id-sha1 object identifier and an absent 371 hashAlgorithm field as an indication that SHA-1 was used. 373 maskGenAlgorithm 375 The maskGenAlgorithm field identifies the mask generation 376 function. The default mask generation function is MGF1 with 377 SHA-1. For MGF1, it is strongly RECOMMENDED that the 378 underlying hash function be the same as the one identified by 379 hashAlgorithm. Implementations MUST support MGF1. MGF1 380 requires a one-way hash function, and it is identified in the 381 parameters field of the MGF1 algorithm identifier. 382 Implementations MUST support SHA-1, and implementations MAY 383 support other one-way hash functions listed in section 2.1. 384 The MGF1 algorithm identifier is comprised of the id-mgf1 385 object identifier and a parameter that contains the algorithm 386 identifier of the one-way hash function employed with MGF1. 387 The SHA-1 algorithm identifier is comprised of the id-sha1 388 object identifier and an (optional) parameter of NULL. 389 Implementations that perform signature generation MUST omit 390 the maskGenAlgorithm field when MGF1 with SHA-1 is used, 391 indicating that the default algorithm was used. 393 Although mfg1SHA1Identifier is defined as the default value 394 for this field, implementations MUST accept both the default 395 value encoding (i.e. an absent field) and mfg1SHA1Identifier 396 to be explicitly present in the encoding. 398 saltLength 400 The saltLength field is the octet length of the salt. For a 401 given hashAlgorithm, the minimum value of saltLength is the 402 number of octets in the hash value. Unlike the other fields 403 of type RSASSA-PSS-params, saltLength does not need to be 405 fixed for a given RSA key pair; a different value could be 406 used for each RSASSA-PSS signature generated. 408 trailerField 410 The trailerField field is an integer. It provides 411 compatibility with the draft IEEE P1363a [P1363a]. The value 412 MUST be 1, which represents the trailer field with hexadecimal 413 value 0xBC. Other trailer fields, including the trailer field 414 composed of HashID concatenated with 0xCC that is specified in 415 IEEE P1363a, are not supported. Implementations that perform 416 signature generation MUST omit the trailerField field, 417 indicating that the default trailer field value was used. 418 Implementations that perform signature validation MUST 419 recognize both a present trailerField field with value 1 and 420 an absent trailerField field. 422 If the default values of the hashAlgorithm, maskGenAlgorithm, and 423 trailerField fields of RSASSA-PSS-params are used, then the 424 algorithm identifier will have the following value: 426 rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { 427 id-RSASSA-PSS, rSASSA-PSS-Default-Params } 429 rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= { 430 sha1Identifier, mgf1SHA1Identifier, 20, 1} 432 3.2 RSASSA-PSS Signature Values 434 The output of the RSASSA-PSS signature algorithm is an octet string, 435 which has the same length in octets as the RSA modulus n. 437 Signature values in CMS [CMS] are represented as octet strings, and 438 the output is used directly. However, signature values in 439 certificates and CRLs [PROFILE] are represented as bit strings, and 440 conversion is needed. 442 To convert a signature value to a bit string, the most significant 443 bit of the first octet of the signature value SHALL become the first 444 bit of the bit string, and so on through the least significant bit 445 of the last octet of the signature value, which SHALL become the 446 last bit of the bit string. 448 3.3 RSASSA-PSS Signature Parameter Validation 450 Three possible parameter validation scenarios exist for RSASSA-PSS 451 signature values. 453 1. The key is identified by the rsaEncryption algorithm identifier. 454 In this case no parameter validation is needed. 456 2. The key is identified by the id-RSASSA-PSS signature algorithm 457 identifier, but the parameters field is absent. In this case no 458 parameter validation is needed. 460 3. The key is identified by the id-RSASSA-PSS signature algorithm 461 identifier and the parameters are present. In this case all 462 parameters in the signature structure algorithm identifier MUST 463 match the parameters in the key structure algorithm identifier 464 except the saltLength field. The saltLength field in the signature 465 parameters MUST be greater or equal to that in the key parameters 466 field. 468 4 RSAES-OAEP Key Transport Algorithm 470 This section describes the conventions for using the RSAES-OAEP key 471 transport algorithm with the Internet X.509 certificate and CRL 472 profile [PROFILE]. RSAES-OAEP is specified in PKCS #1 version 2.1 473 [P1v2.1]. The five one-way hash functions discussed in section 2.1 474 and the one mask generation function discussed in section 2.2 can be 475 used with RSAES-OAEP. Conforming CAs and applications MUST support 476 RSAES-OAEP key transport algorithm using SHA-1. The other three 477 one-way hash functions MAY also be supported. 479 CAs that issue certificates with the id-RSAES-OAEP algorithm 480 identifier SHOULD require that the parameters be present in the 481 publicKeyAlgorithms field for all certificates. 482 Entities that use a certificate with a publicKeyAlgorithm value of 483 id-RSA-OAEP where the parameters are absent SHOULD use the default 484 set of parameters for RSAES-OAEP-params. Entities that use a 485 certificate with a publicKeyAlgorithm value of rsaEncryption SHOULD 486 use the default set of parameters for RSAES-OAEP-params 488 4.1 RSAES-OAEP Public Keys 490 When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters 491 MUST employ the RSAES-OAEP-params syntax. The parameters may be 492 either absent or present when used as subject public key 493 information. The parameters MUST be present when used in the 494 algorithm identifier associated with an encryption value. 496 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 498 RSAES-OAEP-params ::= SEQUENCE { 499 hashFunc [0] AlgorithmIdentifier DEFAULT 500 sha1Identifier, 501 maskGenFunc [1] AlgorithmIdentifier DEFAULT 503 mgf1SHA1Identifier, 504 pSourceFunc [2] AlgorithmIdentifier DEFAULT 505 pSpecifiedEmptyIdentifier } 507 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 508 { id-pSpecified, nullOctetString } 510 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 512 The fields of type RSAES-OAEP-params have the following meanings: 514 hashFunc 516 The hashFunc field identifies the one-way hash function. It 517 MUST be one of the algorithm identifiers listed in section 518 2.1, and the default hash function is SHA-1. Implementations 519 MUST support SHA-1, and implementations MAY support other one- 520 way hash functions listed in section 2.1. Implementations 521 that perform encryption MUST omit the hashFunc field when SHA- 522 1 is used, indicating that the default algorithm was used. 523 Implementations that perform decryption MUST recognize both 524 the id-sha1 object identifier and an absent hashFunc field as 525 an indication that SHA-1 was used. 527 maskGenFunc 529 The maskGenFunc field identifies the mask generation function. 530 The default mask generation function is MGF1 with SHA-1. For 531 MGF1, it is strongly RECOMMENDED that the underlying hash 532 function be the same as the one identified by hashFunc. 533 Implementations MUST support MGF1. MGF1 requires a one-way 534 hash function, and it is identified in the parameter field of 535 the MGF1 algorithm identifier. Implementations MUST support 536 SHA-1, and implementations MAY support other one-way hash 537 functions listed in section 2.1. The MGF1 algorithm 538 identifier is comprised of the id-mgf1 object identifier and a 539 parameter that contains the algorithm identifier of the one- 540 way hash function employed with MGF1. The SHA-1 algorithm 541 identifier is comprised of the id-sha1 object identifier and 542 an (optional) parameter of NULL. Implementations that perform 543 encryption MUST omit the maskGenFunc field when MGF1 with SHA- 544 1 is used, indicating that the default algorithm was used. 546 Although mfg1SHA1Identifier is defined as the default value 547 for this field, implementations MUST accept both the default 548 value encoding (i.e. an absent field) and the 549 mfg1SHA1Identifier to be explicitly present in the encoding. 551 pSourceFunc 553 The pSourceFunc field identifies the source (and possibly the 554 value) of the encoding parameters, commonly called P. 555 Implementations MUST represent P by an algorithm identifier, 556 id-pSpecified, indicating that P is explicitly provided as an 557 OCTET STRING in the parameters. The default value for P is an 559 empty string. In this case, pHash in EME-OAEP contains the 560 hash of a zero length string. Implementations MUST support a 561 zero length P value. Implementations that perform encryption 562 MUST omit the pSourceFunc field when a zero length P value is 563 used, indicating that the default value was used. 564 Implementations that perform decryption MUST recognize both 565 the id-pSpecified object identifier and an absent pSourceFunc 566 field as an indication that a zero length P value was used. 567 Implementations that perform decryption MUST support a zero 568 length P value, and they MAY support other values. Compliant 569 implementations MUST NOT use any value other than id- 570 pSpecifieid for pSourceFunc. 572 If the default values of the hashFunc, maskGenFunc, and pSourceFunc 573 fields of RSAES-OAEP-params are used, then the algorithm identifier 574 will have the following value: 576 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 577 { id-RSAES-OAEP, 578 rSAES-OAEP-Default-Params } 580 rSAES-OAEP-Default-Params RSASSA-OAEP-params ::= 581 { sha1Identifier, 582 mgf1SHA1Identifier, 583 pSpecifiedEmptyIdentifier } 585 5 PKCS #1 Version 1.5 Signature Algorithm 587 RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature 588 algorithm. This specification is also included in PKCS #1 Version 589 2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1 590 Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 591 one-way hash functions. This section specifies the algorithm 592 identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 593 one-way hash functions with the PKCS #1 version 1.5 signature 594 algorithm. 596 The RSASSA-PSS signature algorithm is preferred over the PKCS #1 597 Version 1.5 signature algorithm. Although no attacks are known 598 against PKCS #1 Version 1.5 signature algorithm, in the interest of 599 increased robustness, RSASSA-PSS signature algorithm is recommended 600 for eventual adoption, especially by new applications. This section 601 is included for compatibility with existing applications, and while 602 still appropriate for new applications, a gradual transition to the 603 RSASSA-PSS signature algorithm is encouraged. 605 The PKCS #1 Version 1.5 signature algorithm with these one-way hash 606 functions and the RSA encryption algorithm is implemented using the 607 padding and encoding conventions described in RFC 2313 [P1v1.5]. 609 The message digest is computed using the SHA-224, SHA-256, SHA-384, 610 or SHA-512 one-way hash function. 612 The PKCS #1 version 1.5 signature algorithm, as specified in RFC 613 2313 includes a data encoding step. In this step, the message 614 digest and the object identifier for the one-way hash function used 615 to compute the message digest are combined. When performing the 616 data encoding step, the id-sha224, id-sha256, id-sha384, and id- 617 sha512 object identifiers (see section 2.1) MUST be used to specify 618 the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions, 619 respectively. 621 The object identifier used to identify the PKCS #1 version 1.5 622 signature algorithm with SHA-224 is: 624 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 } 626 The object identifier used to identify the PKCS #1 version 1.5 627 signature algorithm with SHA-256 is: 629 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 631 The object identifier used to identify the PKCS #1 version 1.5 632 signature algorithm with SHA-384 is: 634 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 636 The object identifier used to identify the PKCS #1 version 1.5 637 signature algorithm with SHA-512 is: 639 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 641 When any of these three object identifiers appears within an 642 AlgorithmIdentifier, the parameters MUST be NULL. Implementations 643 MUST accept the parameters being absent as well as present. 645 The RSA signature generation process and the encoding of the result 646 is described in detail in RFC 2313 [P1v1.5]. 648 6 ASN.1 Module 650 PKIX1-PSS-OAEP-Algorithms 651 { iso(1) identified-organization(3) dod(6) 652 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 653 id-mod-pkix1-rsa-pkalgs(33) } 655 DEFINITIONS EXPLICIT TAGS ::= BEGIN 657 -- EXPORTS All; 659 IMPORTS 661 AlgorithmIdentifier 662 FROM PKIX1Explicit88 -- Found in [PROFILE] 663 { iso(1) identified-organization(3) dod(6) internet(1) 664 security(5) mechanisms(5) pkix(7) id-mod(0) 665 id-pkix1-explicit(18) } ; 667 -- ============================ 668 -- Basic object identifiers 669 -- ============================ 671 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 672 us(840) rsadsi(113549) pkcs(1) 1 } 674 -- When rsaEncryption is used in an AlgorithmIdentifier the 675 -- parameters MUST be present and MUST be NULL. 677 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 679 -- When id-RSAES-OAEP is used in an AlgorithmIdentifier, 680 -- and the parameters field is present, it MUST be RSAES-OAEP-params 682 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 684 -- When id-pSpecified is used in an AlgorithmIdentifier the 685 -- parameters MUST be an OCTET STRING. 687 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 689 -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the 690 -- parameters field is present, it MUST be RSASSA-PSS-params. 692 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 694 -- When id-mgf1 is used in an AlgorithmIdentifier the parameters 695 -- MUST be present and MUST be a HashAlgorithm. 697 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 699 -- When the following OIDs are used in an AlgorithmIdentifier, the 700 -- parameters MUST be present and MUST be NULL. 702 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 } 704 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 706 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 708 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 710 -- When the following OIDs are used in an AlgorithmIdentifier the 712 -- parameters SHOULD be absent, but if the parameters are present, 713 -- they MUST be NULL. 715 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 716 identified-organization(3) oiw(14) 717 secsig(3) algorithms(2) 26 } 719 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 720 country(16) us(840) organization(1) gov(101) 721 csor(3) nistalgorithm(4) hashalgs(2) 4 } 723 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 724 country(16) us(840) organization(1) gov(101) 725 csor(3) nistalgorithm(4) hashalgs(2) 1 } 727 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 728 country(16) us(840) organization(1) gov(101) 729 csor(3) nistalgorithm(4) hashalgs(2) 2 } 731 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 732 country(16) us(840) organization(1) gov(101) 733 csor(3) nistalgorithm(4) hashalgs(2) 3 } 735 -- ============= 736 -- Constants 737 -- ============= 739 nullOctetString OCTET STRING (SIZE (0)) ::= ''H 741 nullParameters NULL ::= NULL 743 -- ========================= 744 -- Algorithm Identifiers 745 -- ========================= 747 sha1Identifier AlgorithmIdentifier ::= { 748 algorithm id-sha1, 749 parameters nullParameters } 751 sha224Identifier AlgorithmIdentifier ::= { 752 algorithm id-sha224, 753 parameters nullParameters } 755 sha256Identifier AlgorithmIdentifier ::= { 756 algorithm id-sha256, 757 parameters nullParameters } 759 sha384Identifier AlgorithmIdentifier ::= { 760 algorithm id-sha384, 761 parameters nullParameters } 763 sha512Identifier AlgorithmIdentifier ::= { 764 algorithm id-sha512, 765 parameters nullParameters } 767 mgf1SHA1Identifier AlgorithmIdentifier ::= { 768 algorithm id-mgf1, 769 parameters sha1Identifier } 771 mgf1SHA224Identifier AlgorithmIdentifier ::= { 772 algorithm id-mgf1, 773 parameters sha224Identifier } 775 mgf1SHA256Identifier AlgorithmIdentifier ::= { 776 algorithm id-mgf1, 777 parameters sha256Identifier } 779 mgf1SHA384Identifier AlgorithmIdentifier ::= { 780 algorithm id-mgf1, 781 parameters sha384Identifier } 783 mgf1SHA512Identifier AlgorithmIdentifier ::= { 784 algorithm id-mgf1, 785 parameters sha512Identifier } 787 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= { 788 algorithm id-pSpecified, 789 parameters nullOctetString } 791 rSASSA-PSS-Default-Params RSASSA-PSS-params ::= { 792 hashAlgorithm sha1Identifier, 793 maskGenAlgorithm mgf1SHA1Identifier, 794 saltLength 20, 795 trailerField 1 } 797 rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= { 798 algorithm id-RSASSA-PSS, 799 parameters rSASSA-PSS-Default-Params } 801 rSASSA-PSS-SHA224-Identifier AlgorithmIdentifier ::= { 802 algorithm id-RSASSA-PSS, 803 parameters rSASSA-PSS-SHA224-Params } 805 rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::= { 806 hashAlgorithm sha224Identifier, 807 maskGenAlgorithm mgf1SHA224Identifier, 808 saltLength 20, 809 trailerField 1 } 811 rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= { 812 algorithm id-RSASSA-PSS, 813 parameters rSASSA-PSS-SHA256-Params } 815 rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::= { 816 hashAlgorithm sha256Identifier, 817 maskGenAlgorithm mgf1SHA256Identifier, 818 saltLength 20, 819 trailerField 1 } 821 rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= { 822 algorithm id-RSASSA-PSS, 823 parameters rSASSA-PSS-SHA384-Params } 825 rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= { 826 hashAlgorithm sha384Identifier, 827 maskGenAlgorithm mgf1SHA384Identifier, 828 saltLength 20, 829 trailerField 1 } 831 rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { 832 algorithm id-RSASSA-PSS, 833 parameters rSSASSA-PSS-SHA512-params } 835 rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { 836 hashAlgorithm sha512Identifier, 837 maskGenAlgorithm mgf1SHA512Identifier, 838 saltLength 20, 839 trailerField 1 } 841 rSAES-OAEP-Default-Params RSAES-OAEP-params ::= { 842 hashFunc sha1Identifier, 843 maskGenFunc mgf1SHA1Identifier, 844 pSourceFunc pSpecifiedEmptyIdentifier } 846 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= { 847 algorithm id-RSAES-OAEP, 848 parameters rSAES-OAEP-Default-Params } 850 rSAES-OAEP-SHA224-Identifier AlgorithmIdentifier ::= { 851 algorithm id-RSAES-OAEP, 852 parameters rSAES-OAEP-SHA224-Params } 854 rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::= { 855 hashFunc sha224Identifier, 856 maskGenFunc mgf1SHA224Identifier, 857 pSourceFunc pSpecifiedEmptyIdentifier } 859 rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= { 860 algorithm id-RSAES-OAEP, 861 parameters rSAES-OAEP-SHA256-Params } 863 rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::= { 864 hashFunc sha256Identifier, 866 maskGenFunc mgf1SHA256Identifier, 867 pSourceFunc pSpecifiedEmptyIdentifier } 869 rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= { 870 algorithm id-RSAES-OAEP, 871 parameters rSAES-OAEP-SHA384-Params } 873 rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::= { 874 hashFunc sha384Identifier, 875 maskGenFunc mgf1SHA384Identifier, 876 pSourceFunc pSpecifiedEmptyIdentifier } 878 rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= { 879 algorithm id-RSAES-OAEP, 880 parameters rSAES-OAEP-SHA512-Params } 882 rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::= { 883 hashFunc sha512Identifier, 884 maskGenFunc mgf1SHA512Identifier, 885 pSourceFunc pSpecifiedEmptyIdentifier } 887 -- =================== 888 -- Main structures 889 -- =================== 891 -- Used in SubjectPublicKeyInfo of X.509 Certificate. 893 RSAPublicKey ::= SEQUENCE { 894 modulus INTEGER, -- n 895 publicExponent INTEGER } -- e 897 -- AlgorithmIdentifier parameters for id-RSASSA-PSS. 898 -- Note that the tags in this Sequence are explicit. 900 RSASSA-PSS-params ::= SEQUENCE { 901 hashAlgorithm [0] HashAlgorithm DEFAULT 902 sha1Identifier, 903 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT 904 mgf1SHA1Identifier, 905 saltLength [2] INTEGER DEFAULT 20, 906 trailerField [3] INTEGER DEFAULT 1 } 908 HashAlgorithm ::= AlgorithmIdentifier 910 MaskGenAlgorithm ::= AlgorithmIdentifier 912 -- AlgorithmIdentifier parameters for id-RSAES-OAEP. 913 -- Note that the tags in this Sequence are explicit. 915 RSAES-OAEP-params ::= SEQUENCE { 917 hashFunc [0] AlgorithmIdentifier DEFAULT 918 sha1Identifier, 919 maskGenFunc [1] AlgorithmIdentifier DEFAULT 920 mgf1SHA1Identifier, 921 pSourceFunc [2] AlgorithmIdentifier DEFAULT 922 pSpecifiedEmptyIdentifier } 924 END 926 7 References 928 This section provides normative and informative references. 930 7.1 Normative References 932 [P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 933 RFC 2313, March 1998. 935 [P1v2.1] Jonsson, J., and B. Kaliski, "PKCS #1: RSA 936 Cryptography Specifications Version 2.1", RFC 3447, 937 February 2003. 939 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 940 X.509 Public Key Infrastructure: Certificate and CRL 941 Profile", RFC 3280, April 2002. 943 [SHA2] National Institute of Standards and Technology (NIST), 944 FIPS 180-2: Secure Hash Standard, 1 August 2002. 946 [SHA224] Housley, R, "A 224-bit One-way Hash Function: SHA-224", 947 draft-ietf-pkix-sha224-00.txt, December 2003. 949 [STDWORDS] S. Bradner, "Key Words for Use in RFCs to Indicate 950 Requirement Levels", RFC 2119, March 1997. 952 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 953 Syntax Notation One (ASN.1), 1988. 955 [X.209-88] CCITT Recommendation X.209: Specification of Basic 956 Encoding Rules for Abstract Syntax Notation One (ASN.1), 957 1988. 959 [X.509-88] CCITT Recommendation X.509: The Directory - 960 Authentication Framework. 1988. 962 7.2 Informative References 964 [CMS] Housley, R, "Cryptographic Message Syntax", RFC 3369, 965 August 2002. 967 [GUIDE] National Institute of Standards and Technology, 968 Second Draft: "Key Management Guideline, Part 1: 969 General Guidance." June 2002. 970 [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 972 [P1363a] IEEE P1363 working group, IEEE P1363a D11: Standard 973 Specifications for Public Key Cryptography: Additional 974 Techniques, December 16, 2002 975 Available from http://grouper.ieee.org/groups/1363/. 977 [PKALGS] Polk, W., Housley, R., and L. Bassham, "Algorithms and 978 Identifiers for the Internet X.509 Public Key 979 Infrastructure Certificate and Certificate Revocation 980 Lists (CRL) Profile", RFC 3279, April 2002. 982 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 983 Recommendations for Security, RFC 1750, December 1994. 985 8 Security Considerations 987 This specification supplements RFC 3280 [PROFILE]. The security 988 considerations section of that document applies to this 989 specification as well. 991 Implementations must protect the RSA private key. Compromise of the 992 RSA private key may result in the disclosure of all messages 993 protected with that key. 995 The generation of RSA public/private key pairs relies on a random 996 numbers. The use of inadequate pseudo-random number generators 997 (PRNGs) to generate cryptographic keys can result in little or no 998 security. An attacker may find it much easier to reproduce the PRNG 999 environment that produced the keys, searching the resulting small 1000 set of possibilities, rather than brute force searching the whole 1001 key space. The generation of quality random numbers is difficult. 1002 RFC 1750 [RANDOM] offers important guidance in this area. 1004 Generally, good cryptographic practice employs a given RSA key pair 1005 in only one scheme. This practice avoids the risk that 1006 vulnerability in one scheme may compromise the security of the 1007 other, and may be essential to maintain provable security. While 1008 PKCS #1 Version 1.5 [P1v1.5] has been employed for both key 1009 transport and digital signature without any known bad interactions, 1010 such a combined use of an RSA key pair is not recommended in the 1011 future. Therefore, an RSA key pair used for RSASSA-PSS signature 1012 generation should not also be used for other purposes. For similar 1013 reasons, one RSA key pair should always be used with the same 1014 RSASSA-PSS parameters. Likewise, an RSA key pair used for RSAES- 1015 OAEP key transport should not also be used for other purposes. For 1016 similar reasons, one RSA key pair should always be used with the 1017 same RSAES-OAEP parameters. 1019 This specification requires implementations to support the SHA-1 1020 one-way hash function for interoperability, but support for other 1021 one-way hash function is permitted. At the time of this writing, 1022 the best (known) collision attacks against SHA-1 are generic attacks 1023 with complexity 2^80, where 80 is one-half the bit length of the 1024 hash value. In general, when a one-way hash function is used with a 1025 digital signature scheme, a collision attack is easily translated 1026 into a signature forgery. Therefore, the use of SHA-1 in a digital 1027 signature scheme provides a security level of no more than 80 bits. 1028 If a greater level of security is desired, then a secure one-way 1029 hash function with a longer hash value is needed. SHA-256, SHA-384, 1030 and SHA-512 are reasonable choices [SHA2]. 1032 The metrics for choosing a one-way hash function for use in digital 1033 signatures do not directly apply to the RSAES-OAEP key transport 1034 algorithm, since a collision attack on the one-way hash function 1035 does not directly translate into an attack on the key transport 1036 algorithm, unless the encoding parameters P varies (in which case a 1037 collision the hash value for different encoding parameters might be 1038 exploited). 1040 Nevertheless, for consistency with the practice for digital 1041 signature schemes, and in case the encoding parameters P is not the 1042 empty string, it is recommended that the same rule of thumb be 1043 applied to selection of a one-way hash function for use with RSAES- 1044 OAEP. That is, the one-way hash function should be selected so that 1045 the bit length of the hash value is at least twice as long as the 1046 desired security level in bits. 1048 The key size selected impacts the strength achieved when 1049 implementing cryptographic services. Thus, selection of appropriate 1050 key sizes is critical to implementing appropriate security. A 1024- 1051 bit RSA public key and SHA-1 both provide a security level of about 1052 80 bits. In [GUIDE], the National Institute of Standards and 1053 Technology (NIST) suggest that a security level of 80 bits is 1054 adequate for the protection of sensitive information until 2015. 1055 This recommendation is likely to be revised based on recent 1056 advances, and the revised recommendation is expected to be more 1057 conservative, suggesting that a security level of 80 bits is 1058 adequate for the protection of sensitive information until 2010. If 1059 a security level greater than 80 bits is needed, then a longer RSA 1060 public key and a secure one-way hash function with a longer hash 1061 value are needed. SHA-224, SHA-256, SHA-384, and SHA-512 are 1062 reasonable choices for such a one-way hash function and, for this 1063 reason, the algorithm identifiers for these one-way hash functions 1064 are included in the ASN.1 module in section 6. 1066 Current implementations MUST support 1024-bit RSA public key sizes. 1067 Before the end of 2007, implementations SHOULD support RSA public 1068 key sizes of at least 2048 bits and SHOULD support SHA-256. This 1070 requirement is intended to allow adequate time for users to deploy 1071 the stronger digital signature capability by 2010. 1073 When using RSASSA-PSS, the same one-way hash function should be 1074 employed for the hashAlgorithm and the maskGenAlgorithm, but it is 1075 not required. Using the same one-way hash function helps with 1076 security analysis, and it reduces implementation complexity. 1077 When using RSAES-OAEP, the same one-way hash function should be 1078 employed for the hashFunc and the maskGenFunc, but it is not 1079 required. In each case, using the same one-way hash function helps 1080 with security analysis, and it reduces implementation complexity. 1082 9 IANA Considerations 1084 Within the certificates and CRLs, algorithms are identified by 1085 object identifiers. All of the object identifiers used in this 1086 document were assigned in Public-Key Cryptography Standards (PKCS) 1087 documents or by the National Institute of Standards and Technology 1088 (NIST). No further action by the IANA is necessary for this 1089 document or any anticipated updates. 1091 10 Author Addresses 1093 Russell Housley 1094 Vigil Security, LLC 1095 918 Spring Knoll Drive 1096 Herndon, VA 20170 1097 USA 1098 housley@vigilsec.com 1100 Burt Kaliski 1101 RSA Laboratories 1102 174 Middlesex Turnpike 1103 Bedford, MA 01730 1104 USA 1105 bkaliski@rsasecurity.com 1107 Jim Schaad 1108 Soaring Hawk Consulting 1109 PO Box 675 1110 Gold Bar, WA 98251 1111 USA 1112 jimsch@exmsft.com 1114 11 Full Copyright Statement 1116 Copyright (C) The Internet Society (2004). All Rights Reserved. 1118 This document and translations of it may be copied and furnished to 1119 others, and derivative works that comment on or otherwise explain it 1120 or assist in its implementation may be prepared, copied, published 1122 and distributed, in whole or in part, without restriction of any 1123 kind, provided that the above copyright notice and this paragraph 1124 are included on all such copies and derivative works. 1125 In addition, the ASN.1 modules presented in Section 5 may be used in 1126 whole or in part without inclusion of the copyright notice. However, 1127 this document itself may not be modified in any way, such as by 1128 removing the copyright notice or references to the Internet Society 1129 or other Internet organizations, except as needed for the purpose of 1130 developing Internet standards in which case the procedures for 1131 copyrights defined in the Internet Standards process shall be 1132 followed, or as required to translate it into languages other than 1133 English. 1134 The limited permissions granted above are perpetual and will not be 1135 revoked by the Internet Society or its successors or assigns. This 1136 document and the information contained herein is provided on an "AS 1137 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1138 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1139 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1140 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1141 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.