Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
draft-ietf-pkix-rsa-pkalgs-03

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (pkix WG)
Authors Russ Housley  , Jim Schaad , Burt Kaliski 
Last updated 2020-01-21 (latest revision 2004-03-19)
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4055 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Steven Bellovin
Send notices to wpolk@nist.gov
PKIX Working Group             J. Schaad (Soaring Hawk Consulting) 
Internet Draft                       B. Kaliski (RSA Laboratories) 
                                       R. Housley (Vigil Security) 
expires September 2004                                  March 2004 
    
       Additional Algorithms and Identifiers for RSA Cryptography 
        for use in the Internet X.509 Public Key Infrastructure 
       Certificate and Certificate Revocation List (CRL) Profile 
                  <draft-ietf-pkix-rsa-pkalgs-03.txt> 
    
    
Status of this Memo 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups.  Note that other groups may also 
   distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Drafts Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This document supplements RFC 3279.  It describes the conventions 
   for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
   transport algorithm and additional one-way hash functions with the 
   PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 
   Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, 
   and parameter formats are specified. 
    
Table of Contents 
 
1  Introduction.......................................................2 
 1.1  Terminology....................................................2 
 1.2  RSA Public Keys................................................2 
2  Common Functions...................................................5 
 2.1  One-way Hash Functions.........................................5 
 2.2  Mask Generation Functions......................................6 
3  RSASSA-PSS Signature Algorithm.....................................7 
 3.1  RSASSA-PSS Public Keys.........................................7 
 3.2  RSASSA-PSS Signature Values....................................9 
 3.3  RSASSA-PSS Signature Parameter Validation......................9 
Schaad, Kaliski & Housley                             Page 1 

4  RSAES-OAEP Key Transport Algorithm................................10 
 4.1  RSAES-OAEP Public Keys........................................10 
5  PKCS #1 Version 1.5 Signature Algorithm...........................12 
6  ASN.1 Module......................................................13 
7  References........................................................19 
 7.1  Normative References..........................................19 
 7.2  Informative References........................................19 
8  Security Considerations...........................................20 
10  Author Addresses.................................................22 
11  Full Copyright Statement.........................................22 
    

1  Introduction 
    
   This document supplements RFC 3279 [PKALGS].  This document 
   describes the conventions for using the RSASSA-PSS signature 
   algorithm and the RSAES-OAEP key transport algorithm in the Internet 
   X.509 Public Key Infrastructure (PKI) [PROFILE].  Both of these RSA-
   based algorithms are specified in [P1v2.1].  The algorithm 
   identifiers and associated parameters for subject public keys that 
   employ either of these algorithms are specified, and the encoding 
   format for RSASSA-PSS signatures is specified.  Also, the algorithm 
   identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 
   one-way hash functions with the PKCS #1 version 1.5 signature 
   algorithm [P1v1.5] are specified. 
    
   This specification supplements RFC 3280 [PROFILE], which profiles 
   the X.509 Certificates and Certificate Revocation Lists (CRLs) for 
   use in the Internet.  This specification extends the list of 
   algorithms discussed in RFC 3279 [PKALGS].  The X.509 Certificate 
   and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules 
   (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-
   88]. 
    
   This specification defines the contents of the signatureAlgorithm, 
   signatureValue, signature, and subjectPublicKeyInfo fields within 
   Internet X.509 certificates and CRLs.  For each algorithm, the 
   appropriate alternatives for the keyUsage extension are provided. 

1.1  Terminology 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [STDWORDS]. 

1.2  RSA Public Keys 
    
   RFC 3280 [PROFILE] specifies the profile for using X.509 
   Certificates in Internet applications.  When a RSA public key will 
Schaad, Kaliski & Housley                             Page 2 

   be used for RSASSA-PSS digital signatures or RSAES-OAEP key 
   transport, the conventions specified in this section augment RFC 
   3280. 
    
   Traditionally, the rsaEncryption object identifier is used to 
   identify RSA public keys.  However, to implement all of the 
   recommendations described in the Security Considerations section of 
   this document (see section 8), the certificate user needs to be able 
   to determine the form of digital signature or key transport that the 
   RSA private key owner associates with the public key. 
    
   The rsaEncryption object identifier continues to identify the 
   subject public key when the RSA private key owner does not wish to 
   limit the use of the public key exclusively to either RSASSA-PSS or 
   RSAES-OAEP.  In this case, the rsaEncryption object identifier MUST 
   be used in the algorithm field within the subject public key 
   information, and the parameters field MUST contain NULL. 
    
      rsaEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 1 } 
       
   Further discussion of the conventions associated with use of the 
   rsaEncryption object identifier can be found in RFC 3279 (see 
   [PKALGS], section 2.3.1). 
    
   When the RSA private key owner wishes to limit the use of the public 
   key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object 
   identifier MUST be used in the algorithm field within the subject 
   public key information, and, if present, the parameters field MUST 
   contain RSASSA-PSS-params.  The id-RSASSA-PSS object identifier 
   value and the RSASSA-PSS-params syntax are fully described in 
   section 3 of this document. 
    
   When the RSA private key owner wishes to limit the use of the public 
   key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object 
   identifier MUST be used in the algorithm field within the subject 
   public key information, and, if present, the parameters field MUST 
   contain RSAES-OAEP-params.  The id-RSAES-OAEP object identifier 
   value and the RSAES-OAEP-params syntax are fully described in 
   section 4 of this document. 
    
   Note: It is not possible to restrict the use of a key to only just 
   two of the algorithms (i.e. RSASSA-PSS and RSAES-OAEP) in this 
   document. 
    
   Regardless of the object identifier used, the RSA public key is 
   encoded in the same manner in the subject public key information.  
   The RSA public key MUST be encoded using the type RSAPublicKey type: 
    
      RSAPublicKey  ::=  SEQUENCE  { 
         modulus            INTEGER,    -- n 
         publicExponent     INTEGER  }  -- e 

Schaad, Kaliski & Housley                             Page 3 

    
   Here, the modulus is the modulus n, and publicExponent is the public 
   exponent e.  The DER encoded RSAPublicKey is carried in the 
   subjectPublicKey BIT STRING within the subject public key 
   information. 
    
   The intended application for the key MAY be indicated in the key 
   usage certificate extension (see [PROFILE], section 4.2.1.3). 
    
   If the keyUsage extension is present in an end entity certificate 
   that conveys an RSA public key with the id-RSASSA-PSS object 
   identifier, then the key usage extension MUST contain one or both of 
   the following values: 
    
      nonRepudiation; and 
      digitalSignature. 
    
   If the keyUsage extension is present in a certification authority 
   certificate that conveys an RSA public key with the id-RSASSA-PSS 
   object identifier, then the key usage extension MUST contain one or 
   more of the following values: 
    
      nonRepudiation; 
      digitalSignature; 
      keyCertSign; and 
      cRLSign. 
    
   When a certificate that conveys an RSA public key with the id-
   RSASSA-PSS object identifier, the certificate user MUST only use the 
   certified RSA public key for RSASSA-PSS operations, and, if RSASSA-
   PSS-params is present, the certificate user MUST perform those 
   operations using the one-way hash function, mask generation 
   function, and trailer field identified in the subject public key 
   algorithm identifier parameters within the certificate. 
    
   If the keyUsage extension is present in a certificate that conveys 
   an RSA public key with the id-RSAES-OAEP object identifier, then the 
   key usage extension MUST contain only the following values: 
    
      keyEncipherment; and 
      dataEncipherment. 
    
   However, both keyEncipherment and dataEncipherment SHOULD NOT be 
   present. 
    
   When a certificate that conveys an RSA public key with the id-RSAES-
   OAEP object identifier, the certificate user MUST only use the 
   certified RSA public key for RSAES-OAEP operations, and, if RSAES-
   OAEP-params is present, the certificate user MUST perform those 
   operations using the one-way hash function and mask generation 

Schaad, Kaliski & Housley                             Page 4 

   function identified in the subject public key algorithm identifier 
   parameters within the certificate. 
    

2  Common Functions 
    
   The RSASSA-PSS signature algorithm and the RSAES-OAEP key transport 
   algorithm make use of one-way hash functions and mask generation 
   functions. 

2.1  One-way Hash Functions 
    
   PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions 
   for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP 
   key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 
   [SHA2].  This document adds additional support for SHA-224 [SHA-224] 
   with both the RSASSA-PSS and the RSAES-OAEP algorithms.  While 
   support for additional one-way hash functions could be added in the 
   future, no other one-way hash functions are supported by this 
   specification. 
    
   These one-way hash functions are identified by the following object 
   identifiers: 
    
      id-sha1  OBJECT IDENTIFIER  ::=  { iso(1) 
                           identified-organization(3) oiw(14) 
                           secsig(3) algorithms(2) 26 } 
      id-sha224  OBJECT IDENTIFIER  ::=  {{ joint-iso-itu-t(2) 
                           country(16) us(840) organization(1) gov(101) 
                           csor(3) nistalgorithm(4) hashalgs(2) 4 } 
      id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                           country(16) us(840) organization(1) gov(101) 
                           csor(3) nistalgorithm(4) hashalgs(2) 1 } 
      id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                           country(16) us(840) organization(1) gov(101) 
                           csor(3) nistalgorithm(4) hashalgs(2) 2 } 
      id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                           country(16) us(840) organization(1) gov(101) 
                           csor(3) nistalgorithm(4) hashalgs(2) 3 } 
    
   There are two possible encodings for the AlgorithmIdentifier 
   parameters field associated with these object identifiers.  The two 
   alternatives arise from the fact that when the 1988 syntax for 
   AlgorithmIdentifier was translated into the 1997 syntax the OPTIONAL 
   associated with the algorithm identifier parameters got lost.  Later 
   the OPTIONAL was recovered via a defect report, but by then many 
   people thought that algorithm parameters were mandatory.  Because of 
   this history some implementations encode parameters as a NULL 
   element and others omit them entirely.  The correct encoding is to 
   omit the parameters field; however, at the time that RSASSA-PSS and 

Schaad, Kaliski & Housley                             Page 5 

   RSAES-OAEP were defined it was done using the NULL parameters rather 
   than absent parameters. 
    
   All implementations MUST accept both NULL and absent parameters as 
   legal and equivalent encodings. 
    
   To be clear, the following algorithm identifiers are used when a 
   NULL parameter MUST be present: 
    
      sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, NULL } 
       
      sha224Identifier  AlgorithmIdentifier  ::=  { id-sha224, NULL } 
      sha256Identifier  AlgorithmIdentifier  ::=  { id-sha256, NULL } 
      sha384Identifier  AlgorithmIdentifier  ::=  { id-sha384, NULL } 
      sha512Identifier  AlgorithmIdentifier  ::=  { id-sha512, NULL } 

2.2  Mask Generation Functions 
    
   One mask generation function is used with the RSASSA-PSS signature 
   algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1].  
   No other mask generation functions are supported by this 
   specification. 
    
   MGF1 is identified by the following object identifier: 
    
      id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 } 
    
   The parameters field associated with id-mgf1 MUST have a 
   hashAlgorithm value, which identifies the hash function being used 
   with MGF1.  This value MUST be sha1Identifier, sha224Identifier, 
   sha256Identifier, sha384Identifier, or sha512Identifier, as 
   specified in section 2.1.  Implementations MUST support the default 
   value, sha1Identifier, and implementations MAY support the other 
   four values. 
    
   The following algorithm identifiers have been assigned for each of 
   these alternatives: 
    
      mgf1SHA1Identifier  AlgorithmIdentifier  ::= 
                           { id-mgf1, sha1Identifier } 
      mgf1SHA224Identifier  AlgorithmIdentifier  ::= 
                           { id-mgf1, sha224Identifier } 
      mgf1SHA256Identifier  AlgorithmIdentifier  ::= 
                           { id-mgf1, sha256Identifier } 
      mgf1SHA384Identifier  AlgorithmIdentifier  ::= 
                           { id-mgf1, sha384Identifier } 
      mgf1SHA512Identifier  AlgorithmIdentifier  ::= 
                           { id-mgf1, sha512Identifier } 
    

Schaad, Kaliski & Housley                             Page 6 

3  RSASSA-PSS Signature Algorithm 
    
   This section describes the conventions for using the RSASSA-PSS 
   signature algorithm with the Internet X.509 certificate and CRL 
   profile [PROFILE].  The RSASSA-PSS signature algorithm is specified 
   in PKCS #1 version 2.1 [P1v2.1].  The five one-way hash functions 
   discussed in section 2.1 and the one mask generation function 
   discussed in section 2.2 can be used with RSASSA-PSS.   
    
   CAs that issue certificates with the id-RSASSA-PSS algorithm 
   identifier SHOULD require that the parameters be present in the 
   publicKeyAlgorithms field if the cA boolean flag is set in the basic 
   constraints extension.  CAs MAY require that the parameters be 
   present in the publicKeyAlgorithms field for end-entity 
   certificates. 
    
   CAs that use the RSASSA-PSS algorithm for signing certificates, 
   SHOULD have RSASSA-PSS-params the parameters present in their own 
   certificates.  CAs that use the RSASSA-PSS algorithm for signing, 
   certificates and CRLs MUST include RSASSA-PSS-params the parameters 
   in the signature algorithm field of the TBSCertificate and 
   TBSCertList structures. 
    
   Entities that validate RSASSA-PSS signatures MUST have support for 
   SHA-1.  They MAY also support the other hashing algorithms in 
   section 2.1. 
    
   The data to be signed (e.g., the one-way hash function output value) 
   is formatted for the signature algorithm to be used.  Then, a 
   private key operation (e.g., RSA encryption) is performed to 
   generate the signature value.  This signature value is then ASN.1 
   encoded as a BIT STRING and included in the Certificate or 
   CertificateList in the signature field.  Section 3.2 specifies the 
   format of RSASSA-PSS signature values. 

3.1  RSASSA-PSS Public Keys 
    
   When RSASSA-PSS is used in an AlgorithmIdentifier,the parameters 
   MUST employ the RSASSA-PSS-params syntax.  The parameters may be 
   either absent or present when used as subject public key 
   information.  The parameters MUST be present when used in the 
   algorithm identifier associated with for a signature value. 
    
   When signing, it is RECOMMENDED that, except for saltLength, the 
   parameters remain fixed for all usages of a given RSA key pair.   
    
      id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 } 
       
      RSASSA-PSS-params  ::=  SEQUENCE  { 
         hashAlgorithm      [0] HashAlgorithm DEFAULT 
                                   sha1Identifier, 
Schaad, Kaliski & Housley                             Page 7 

         maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT 
                                   mgf1SHA1Identifier, 
         saltLength         [2] INTEGER DEFAULT 20, 
         trailerField       [3] INTEGER DEFAULT 1  } 
    
   The fields of type RSASSA-PSS-params have the following meanings: 
    
      hashAlgorithm 
    
         The hashAlgorithm field identifies the hash function.  It MUST 
         be one of the algorithm identifiers listed in section 2.1, and 
         the default hash function is SHA-1.  Implementations MUST 
         support SHA-1, and implementations MAY support other one-way 
         hash functions listed in section 2.1.  Implementations that 
         perform signature generation MUST omit the hashAlgorithm field 
         when SHA-1 is used, indicating that the default algorithm was 
         used.  Implementations that perform signature validation MUST 
         recognize both the id-sha1 object identifier and an absent 
         hashAlgorithm field as an indication that SHA-1 was used. 
    
      maskGenAlgorithm 
    
         The maskGenAlgorithm field identifies the mask generation 
         function.  The default mask generation function is MGF1 with 
         SHA-1.  For MGF1, it is strongly RECOMMENDED that the 
         underlying hash function be the same as the one identified by 
         hashAlgorithm.  Implementations MUST support MGF1.  MGF1 
         requires a one-way hash function, and it is identified in the 
         parameters field of the MGF1 algorithm identifier.  
         Implementations MUST support SHA-1, and implementations MAY 
         support other one-way hash functions listed in section 2.1.  
         The MGF1 algorithm identifier is comprised of the id-mgf1 
         object identifier and a parameter that contains the algorithm 
         identifier of the one-way hash function employed with MGF1.  
         The SHA-1 algorithm identifier is comprised of the id-sha1 
         object identifier and an (optional) parameter of NULL.  
         Implementations that perform signature generation MUST omit 
         the maskGenAlgorithm field when MGF1 with SHA-1 is used, 
         indicating that the default algorithm was used.   
          
         Although mfg1SHA1Identifier is defined as the default value 
         for this field, implementations MUST accept both the default 
         value encoding (i.e. an absent field) and mfg1SHA1Identifier 
         to be explicitly present in the encoding. 
    
      saltLength 
    
         The saltLength field is the octet length of the salt.  For a 
         given hashAlgorithm, the minimum value of saltLength is the 
         number of octets in the hash value.  Unlike the other fields 
         of type RSASSA-PSS-params, saltLength does not need to be 

Schaad, Kaliski & Housley                             Page 8 

         fixed for a given RSA key pair; a different value could be 
         used for each RSASSA-PSS signature generated. 
    
      trailerField 
       
         The trailerField field is an integer.  It provides 
         compatibility with the draft IEEE P1363a [P1363a].  The value 
         MUST be 1, which represents the trailer field with hexadecimal 
         value 0xBC.  Other trailer fields, including the trailer field 
         composed of HashID concatenated with 0xCC that is specified in 
         IEEE P1363a, are not supported.  Implementations that perform 
         signature generation MUST omit the trailerField field, 
         indicating that the default trailer field value was used.  
         Implementations that perform signature validation MUST 
         recognize both a present trailerField field with value 1 and 
         an absent trailerField field. 
    
   If the default values of the hashAlgorithm, maskGenAlgorithm, and 
   trailerField fields of RSASSA-PSS-params are used, then the 
   algorithm identifier will have the following value: 
    
      rSASSA-PSS-Default-Identifier  AlgorithmIdentifier  ::=  { 
                           id-RSASSA-PSS, rSASSA-PSS-Default-Params } 
       
      rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {  
                           sha1Identifier, mgf1SHA1Identifier, 20, 1} 

3.2  RSASSA-PSS Signature Values 
    
   The output of the RSASSA-PSS signature algorithm is an octet string, 
   which has the same length in octets as the RSA modulus n. 
    
   Signature values in CMS [CMS] are represented as octet strings, and 
   the output is used directly.  However, signature values in 
   certificates and CRLs [PROFILE] are represented as bit strings, and 
   conversion is needed. 
    
   To convert a signature value to a bit string, the most significant 
   bit of the first octet of the signature value SHALL become the first 
   bit of the bit string, and so on through the least significant bit 
   of the last octet of the signature value, which SHALL become the 
   last bit of the bit string. 

3.3  RSASSA-PSS Signature Parameter Validation 
    
   Three possible parameter validation scenarios exist for RSASSA-PSS 
   signature values.   
    
   1. The key is identified by the rsaEncryption algorithm identifier.  
   In this case no parameter validation is needed. 
    
Schaad, Kaliski & Housley                             Page 9 

   2. The key is identified by the id-RSASSA-PSS signature algorithm 
   identifier, but the parameters field is absent.  In this case no 
   parameter validation is needed. 
    
   3. The key is identified by the id-RSASSA-PSS signature algorithm 
   identifier and the parameters are present.  In this case all 
   parameters in the signature structure algorithm identifier MUST 
   match the parameters in the key structure algorithm identifier 
   except the saltLength field.  The saltLength field in the signature 
   parameters MUST be greater or equal to that in the key parameters 
   field. 

4  RSAES-OAEP Key Transport Algorithm 
    
   This section describes the conventions for using the RSAES-OAEP key 
   transport algorithm with the Internet X.509 certificate and CRL 
   profile [PROFILE].  RSAES-OAEP is specified in PKCS #1 version 2.1 
   [P1v2.1].  The five one-way hash functions discussed in section 2.1 
   and the one mask generation function discussed in section 2.2 can be 
   used with RSAES-OAEP.  Conforming CAs and applications MUST support 
   RSAES-OAEP key transport algorithm using SHA-1.  The other three 
   one-way hash functions MAY also be supported. 
    
   CAs that issue certificates with the id-RSAES-OAEP algorithm 
   identifier SHOULD require that the parameters be present in the 
   publicKeyAlgorithms field for all certificates. 
   Entities that use a certificate with a publicKeyAlgorithm value of 
   id-RSA-OAEP where the parameters are absent SHOULD use the default 
   set of parameters for RSAES-OAEP-params.  Entities that use a 
   certificate with a publicKeyAlgorithm value of rsaEncryption SHOULD 
   use the default set of parameters for RSAES-OAEP-params 

4.1  RSAES-OAEP Public Keys 
    
   When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters 
   MUST employ the RSAES-OAEP-params syntax.  The parameters may be 
   either absent or present when used as subject public key 
   information.  The parameters MUST be present when used in the 
   algorithm identifier associated with an encryption value. 
    
      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 } 
       
      RSAES-OAEP-params  ::=  SEQUENCE  { 
         hashFunc          [0] AlgorithmIdentifier DEFAULT 
                                  sha1Identifier, 
         maskGenFunc       [1] AlgorithmIdentifier DEFAULT 
       
                                  mgf1SHA1Identifier, 
         pSourceFunc       [2] AlgorithmIdentifier DEFAULT 
                                  pSpecifiedEmptyIdentifier  } 
       
Schaad, Kaliski & Housley                            Page 10 

      pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::= 
                           { id-pSpecified, nullOctetString } 
       
      nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H } 
    
   The fields of type RSAES-OAEP-params have the following meanings: 
    
      hashFunc 
    
         The hashFunc field identifies the one-way hash function.  It 
         MUST be one of the algorithm identifiers listed in section 
         2.1, and the default hash function is SHA-1.  Implementations 
         MUST support SHA-1, and implementations MAY support other one-
         way hash functions listed in section 2.1.  Implementations 
         that perform encryption MUST omit the hashFunc field when SHA-
         1 is used, indicating that the default algorithm was used.  
         Implementations that perform decryption MUST recognize both 
         the id-sha1 object identifier and an absent hashFunc field as 
         an indication that SHA-1 was used. 
    
      maskGenFunc 
    
         The maskGenFunc field identifies the mask generation function. 
         The default mask generation function is MGF1 with SHA-1.  For 
         MGF1, it is strongly RECOMMENDED that the underlying hash 
         function be the same as the one identified by hashFunc.  
         Implementations MUST support MGF1.  MGF1 requires a one-way 
         hash function, and it is identified in the parameter field of 
         the MGF1 algorithm identifier.  Implementations MUST support 
         SHA-1, and implementations MAY support other one-way hash 
         functions listed in section 2.1.  The MGF1 algorithm 
         identifier is comprised of the id-mgf1 object identifier and a 
         parameter that contains the algorithm identifier of the one-
         way hash function employed with MGF1.  The SHA-1 algorithm 
         identifier is comprised of the id-sha1 object identifier and 
         an (optional) parameter of NULL.  Implementations that perform 
         encryption MUST omit the maskGenFunc field when MGF1 with SHA-
         1 is used, indicating that the default algorithm was used.   
          
         Although mfg1SHA1Identifier is defined as the default value 
         for this field, implementations MUST accept both the default 
         value encoding (i.e. an absent field) and the 
         mfg1SHA1Identifier to be explicitly present in the encoding. 
    
      pSourceFunc 
    
         The pSourceFunc field identifies the source (and possibly the 
         value) of the encoding parameters, commonly called P.  
         Implementations MUST represent P by an algorithm identifier, 
         id-pSpecified, indicating that P is explicitly provided as an 
         OCTET STRING in the parameters.  The default value for P is an 

Schaad, Kaliski & Housley                            Page 11 

         empty string.  In this case, pHash in EME-OAEP contains the 
         hash of a zero length string.  Implementations MUST support a 
         zero length P value.  Implementations that perform encryption 
         MUST omit the pSourceFunc field when a zero length P value is 
         used, indicating that the default value was used.  
         Implementations that perform decryption MUST recognize both 
         the id-pSpecified object identifier and an absent pSourceFunc 
         field as an indication that a zero length P value was used.  
         Implementations that perform decryption MUST support a zero 
         length P value, and they MAY support other values.  Compliant 
         implementations MUST NOT use any value other than id-
         pSpecifieid for pSourceFunc. 
    
   If the default values of the hashFunc, maskGenFunc, and pSourceFunc 
   fields of RSAES-OAEP-params are used, then the algorithm identifier 
   will have the following value: 
    
      rSAES-OAEP-Default-Identifier  AlgorithmIdentifier  ::= 
                            { id-RSAES-OAEP, 
                              rSAES-OAEP-Default-Params } 
       
      rSAES-OAEP-Default-Params RSASSA-OAEP-params ::= 
                               { sha1Identifier, 
                                 mgf1SHA1Identifier, 
                                 pSpecifiedEmptyIdentifier  } 
    

5  PKCS #1 Version 1.5 Signature Algorithm 
    
   RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature 
   algorithm.  This specification is also included in PKCS #1 Version 
   2.1 [P1v2.1].  RFC 3279 [PKALGS] specifies the use of the PKCS #1 
   Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 
   one-way hash functions.  This section specifies the algorithm 
   identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 
   one-way hash functions with the PKCS #1 version 1.5 signature 
   algorithm. 
    
   The RSASSA-PSS signature algorithm is preferred over the PKCS #1 
   Version 1.5 signature algorithm.  Although no attacks are known 
   against PKCS #1 Version 1.5 signature algorithm, in the interest of 
   increased robustness, RSASSA-PSS signature algorithm is recommended 
   for eventual adoption, especially by new applications.  This section 
   is included for compatibility with existing applications, and while 
   still appropriate for new applications, a gradual transition to the 
   RSASSA-PSS signature algorithm is encouraged. 
    
   The PKCS #1 Version 1.5 signature algorithm with these one-way hash 
   functions and the RSA encryption algorithm is implemented using the 
   padding and encoding conventions described in RFC 2313 [P1v1.5].  

Schaad, Kaliski & Housley                            Page 12 

   The message digest is computed using the SHA-224, SHA-256, SHA-384, 
   or SHA-512 one-way hash function. 
    
   The PKCS #1 version 1.5 signature algorithm, as specified in RFC 
   2313 includes a data encoding step.  In this step, the message 
   digest and the object identifier for the one-way hash function used 
   to compute the message digest are combined.  When performing the 
   data encoding step, the id-sha224, id-sha256, id-sha384, and id-
   sha512 object identifiers (see section 2.1) MUST be used to specify 
   the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions, 
   respectively. 
    
   The object identifier used to identify the PKCS #1 version 1.5 
   signature algorithm with SHA-224 is: 
    
      sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 } 
    
   The object identifier used to identify the PKCS #1 version 1.5 
   signature algorithm with SHA-256 is: 
    
      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 } 
    
   The object identifier used to identify the PKCS #1 version 1.5 
   signature algorithm with SHA-384 is: 
    
      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 } 
    
   The object identifier used to identify the PKCS #1 version 1.5 
   signature algorithm with SHA-512 is: 
    
      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 } 
    
   When any of these three object identifiers appears within an 
   AlgorithmIdentifier, the parameters MUST be NULL.  Implementations 
   MUST accept the parameters being absent as well as present. 
    
   The RSA signature generation process and the encoding of the result 
   is described in detail in RFC 2313 [P1v1.5]. 

6  ASN.1 Module 
    
PKIX1-PSS-OAEP-Algorithms 
     { iso(1) identified-organization(3) dod(6) 
       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
       id-mod-pkix1-rsa-pkalgs(33) } 
 
   DEFINITIONS EXPLICIT TAGS ::= BEGIN 
 
   -- EXPORTS All; 
 
   IMPORTS 
Schaad, Kaliski & Housley                            Page 13 

     AlgorithmIdentifier 
         FROM PKIX1Explicit88 -- Found in [PROFILE] 
         { iso(1) identified-organization(3) dod(6) internet(1) 
           security(5) mechanisms(5) pkix(7) id-mod(0) 
           id-pkix1-explicit(18) } ; 
   
 
   -- ============================ 
   --   Basic object identifiers 
   -- ============================ 
 
   pkcs-1  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2) 
                           us(840) rsadsi(113549) pkcs(1) 1 } 
 
   -- When rsaEncryption is used in an AlgorithmIdentifier the 
   -- parameters MUST be present and MUST be NULL. 
 
   rsaEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 1 } 
 
   -- When id-RSAES-OAEP is used in an AlgorithmIdentifier, 
   -- and the parameters field is present, it MUST be RSAES-OAEP-params 
 
   id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 } 
 
   -- When id-pSpecified is used in an AlgorithmIdentifier the 
   -- parameters MUST be an OCTET STRING. 
 
   id-pSpecified  OBJECT IDENTIFIER  ::=  { pkcs-1 9 } 
 
   -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the 
   -- parameters field is present, it MUST be RSASSA-PSS-params. 
 
   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 } 
 
   -- When id-mgf1 is used in an AlgorithmIdentifier the parameters 
   -- MUST be present and MUST be a HashAlgorithm. 
 
   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 } 
 
   -- When the following OIDs are used in an AlgorithmIdentifier, the 
   -- parameters MUST be present and MUST be NULL. 
 
   sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 } 
 
   sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 } 
 
   sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 } 
 
   sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 } 
 
   -- When the following OIDs are used in an AlgorithmIdentifier the 

Schaad, Kaliski & Housley                            Page 14 

   -- parameters SHOULD be absent, but if the parameters are present, 
   -- they MUST be NULL.  
 
   id-sha1  OBJECT IDENTIFIER  ::=  { iso(1) 
                        identified-organization(3) oiw(14) 
                        secsig(3) algorithms(2) 26 } 
 
   id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                        country(16) us(840) organization(1) gov(101) 
                        csor(3) nistalgorithm(4) hashalgs(2) 4 } 
 
   id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                        country(16) us(840) organization(1) gov(101) 
                        csor(3) nistalgorithm(4) hashalgs(2) 1 } 
 
   id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                        country(16) us(840) organization(1) gov(101) 
                        csor(3) nistalgorithm(4) hashalgs(2) 2 } 
 
   id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
                        country(16) us(840) organization(1) gov(101) 
                        csor(3) nistalgorithm(4) hashalgs(2) 3 } 
 
   -- ============= 
   --   Constants 
   -- ============= 
 
   nullOctetString  OCTET STRING (SIZE (0))  ::=  ''H 
 
   nullParameters NULL  ::=  NULL 
    
   -- ========================= 
   --   Algorithm Identifiers 
   -- ========================= 
 
   sha1Identifier  AlgorithmIdentifier  ::=  {  
                           algorithm id-sha1, 
                           parameters nullParameters  } 
 
   sha224Identifier    AlgorithmIdentifier  ::=  { 
                           algorithm id-sha224, 
                           parameters nullParameters  } 
 
   sha256Identifier    AlgorithmIdentifier  ::=  { 
                           algorithm id-sha256, 
                           parameters nullParameters  } 
 
   sha384Identifier    AlgorithmIdentifier  ::=  { 
                           algorithm id-sha384, 
                           parameters nullParameters  } 
 

Schaad, Kaliski & Housley                            Page 15 

   sha512Identifier    AlgorithmIdentifier  ::=  { 
                           algorithm id-sha512, 
                           parameters nullParameters  } 
    
   mgf1SHA1Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-mgf1, 
                           parameters sha1Identifier }  
 
   mgf1SHA224Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-mgf1, 
                           parameters sha224Identifier }  
 
   mgf1SHA256Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-mgf1,  
                           parameters sha256Identifier } 
 
   mgf1SHA384Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-mgf1, 
                           parameters sha384Identifier }  
 
   mgf1SHA512Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-mgf1,  
                           parameters sha512Identifier } 
 
   pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-pSpecified,  
                           parameters nullOctetString } 
 
   rSASSA-PSS-Default-Params RSASSA-PSS-params ::=  { 
                           hashAlgorithm sha1Identifier, 
                           maskGenAlgorithm mgf1SHA1Identifier, 
                           saltLength 20, 
                           trailerField 1  } 
 
   rSASSA-PSS-Default-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSASSA-PSS,  
                           parameters rSASSA-PSS-Default-Params } 
 
   rSASSA-PSS-SHA224-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSASSA-PSS,  
                           parameters rSASSA-PSS-SHA224-Params }  
 
   rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::= { 
                           hashAlgorithm sha224Identifier, 
                           maskGenAlgorithm mgf1SHA224Identifier, 
                           saltLength 20,  
                           trailerField 1  }  
 
   rSASSA-PSS-SHA256-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSASSA-PSS,  
                           parameters rSASSA-PSS-SHA256-Params }  

Schaad, Kaliski & Housley                            Page 16 

 
   rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::=  { 
                           hashAlgorithm sha256Identifier, 
                           maskGenAlgorithm mgf1SHA256Identifier,  
                           saltLength 20,  
                           trailerField 1  }  
 
   rSASSA-PSS-SHA384-Identifier  AlgorithmIdentifier  ::=  {  
                           algorithm id-RSASSA-PSS,  
                           parameters rSASSA-PSS-SHA384-Params } 
 
   rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= { 
                           hashAlgorithm sha384Identifier, 
                           maskGenAlgorithm mgf1SHA384Identifier, 
                           saltLength 20, 
                           trailerField 1  } 
 
   rSASSA-PSS-SHA512-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSASSA-PSS,  
                           parameters rSSASSA-PSS-SHA512-params } 
 
   rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { 
                           hashAlgorithm sha512Identifier, 
                           maskGenAlgorithm mgf1SHA512Identifier, 
                           saltLength 20, 
                           trailerField 1  } 
 
   rSAES-OAEP-Default-Params RSAES-OAEP-params ::=  { 
                           hashFunc sha1Identifier, 
                           maskGenFunc mgf1SHA1Identifier, 
                           pSourceFunc pSpecifiedEmptyIdentifier  } 
 
   rSAES-OAEP-Default-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSAES-OAEP,  
                           parameters rSAES-OAEP-Default-Params }  
 
   rSAES-OAEP-SHA224-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSAES-OAEP,  
                           parameters rSAES-OAEP-SHA224-Params }  
 
   rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::=   { 
                           hashFunc sha224Identifier, 
                           maskGenFunc mgf1SHA224Identifier, 
                           pSourceFunc pSpecifiedEmptyIdentifier  } 
 
   rSAES-OAEP-SHA256-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSAES-OAEP,  
                           parameters rSAES-OAEP-SHA256-Params }  
 
   rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::=  { 
                           hashFunc sha256Identifier,  

Schaad, Kaliski & Housley                            Page 17 

                           maskGenFunc mgf1SHA256Identifier,  
                           pSourceFunc pSpecifiedEmptyIdentifier  }  
 
   rSAES-OAEP-SHA384-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSAES-OAEP, 
                           parameters rSAES-OAEP-SHA384-Params }  
 
   rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::=  { 
                           hashFunc sha384Identifier, 
                           maskGenFunc mgf1SHA384Identifier, 
                           pSourceFunc pSpecifiedEmptyIdentifier  } 
 
   rSAES-OAEP-SHA512-Identifier  AlgorithmIdentifier  ::=  { 
                           algorithm id-RSAES-OAEP,  
                           parameters rSAES-OAEP-SHA512-Params } 
 
   rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::=  { 
                           hashFunc sha512Identifier, 
                           maskGenFunc mgf1SHA512Identifier, 
                           pSourceFunc pSpecifiedEmptyIdentifier  } 
 
   -- =================== 
   --   Main structures 
   -- =================== 
 
   -- Used in SubjectPublicKeyInfo of X.509 Certificate. 
 
   RSAPublicKey  ::=  SEQUENCE  { 
      modulus           INTEGER,    -- n 
      publicExponent    INTEGER  }  -- e  
 
 
   -- AlgorithmIdentifier parameters for id-RSASSA-PSS. 
   -- Note that the tags in this Sequence are explicit. 
 
   RSASSA-PSS-params  ::=  SEQUENCE  { 
      hashAlgorithm     [0] HashAlgorithm DEFAULT  
                               sha1Identifier, 
      maskGenAlgorithm  [1] MaskGenAlgorithm DEFAULT 
                               mgf1SHA1Identifier, 
      saltLength        [2] INTEGER DEFAULT 20, 
      trailerField      [3] INTEGER DEFAULT 1  }  
 
   HashAlgorithm  ::=  AlgorithmIdentifier 
 
   MaskGenAlgorithm  ::=  AlgorithmIdentifier 
 
   -- AlgorithmIdentifier parameters for id-RSAES-OAEP. 
   -- Note that the tags in this Sequence are explicit. 
 
   RSAES-OAEP-params  ::=  SEQUENCE  { 

Schaad, Kaliski & Housley                            Page 18 

      hashFunc          [0] AlgorithmIdentifier DEFAULT 
                               sha1Identifier, 
      maskGenFunc       [1] AlgorithmIdentifier DEFAULT 
                               mgf1SHA1Identifier, 
      pSourceFunc       [2] AlgorithmIdentifier DEFAULT 
                               pSpecifiedEmptyIdentifier  } 
 
   END 

7  References 
    
   This section provides normative and informative references. 

7.1  Normative References 
    
   [P1v1.5]   Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 
              RFC 2313, March 1998. 
    
   [P1v2.1]   Jonsson, J., and B. Kaliski, "PKCS #1: RSA 
              Cryptography Specifications Version 2.1", RFC 3447, 
              February 2003.   
    
   [PROFILE]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 
              X.509 Public Key Infrastructure: Certificate and CRL 
              Profile", RFC 3280, April 2002. 
    
   [SHA2]     National Institute of Standards and Technology (NIST), 
              FIPS 180-2: Secure Hash Standard, 1 August 2002. 
    
   [SHA224]   Housley, R, "A 224-bit One-way Hash Function: SHA-224", 
              draft-ietf-pkix-sha224-00.txt, December 2003. 
    
   [STDWORDS] S. Bradner, "Key Words for Use in RFCs to Indicate 
              Requirement Levels", RFC 2119, March 1997. 
    
   [X.208-88] CCITT Recommendation X.208: Specification of Abstract 
              Syntax Notation One (ASN.1), 1988. 
    
   [X.209-88] CCITT Recommendation X.209: Specification of Basic 
              Encoding Rules for Abstract Syntax Notation One (ASN.1), 
              1988. 
    
   [X.509-88] CCITT Recommendation X.509: The Directory - 
              Authentication Framework.  1988. 

7.2  Informative References 
    
   [CMS]      Housley, R, "Cryptographic Message Syntax", RFC 3369, 
              August 2002. 
    

Schaad, Kaliski & Housley                            Page 19 

   [GUIDE]    National Institute of Standards and Technology, 
              Second Draft: "Key Management Guideline, Part 1: 
              General Guidance."  June 2002. 
              [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 
    
   [P1363a]   IEEE P1363 working group, IEEE P1363a D11: Standard 
              Specifications for Public Key Cryptography: Additional 
              Techniques, December 16, 2002 
              Available from http://grouper.ieee.org/groups/1363/. 
    
   [PKALGS]   Polk, W., Housley, R., and L. Bassham, "Algorithms and 
              Identifiers for the Internet X.509 Public Key 
              Infrastructure Certificate and Certificate Revocation 
              Lists (CRL) Profile", RFC 3279, April 2002. 
    
   [RANDOM]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness 
              Recommendations for Security, RFC 1750, December 1994. 

8  Security Considerations 
    
   This specification supplements RFC 3280 [PROFILE].  The security 
   considerations section of that document applies to this 
   specification as well. 
    
   Implementations must protect the RSA private key.  Compromise of the 
   RSA private key may result in the disclosure of all messages 
   protected with that key. 
    
   The generation of RSA public/private key pairs relies on a random 
   numbers.  The use of inadequate pseudo-random number generators 
   (PRNGs) to generate cryptographic keys can result in little or no 
   security.  An attacker may find it much easier to reproduce the PRNG 
   environment that produced the keys, searching the resulting small 
   set of possibilities, rather than brute force searching the whole 
   key space.  The generation of quality random numbers is difficult.  
   RFC 1750 [RANDOM] offers important guidance in this area. 
    
   Generally, good cryptographic practice employs a given RSA key pair 
   in only one scheme.  This practice avoids the risk that 
   vulnerability in one scheme may compromise the security of the 
   other, and may be essential to maintain provable security.  While 
   PKCS #1 Version 1.5 [P1v1.5] has been employed for both key 
   transport and digital signature without any known bad interactions, 
   such a combined use of an RSA key pair is not recommended in the 
   future.  Therefore, an RSA key pair used for RSASSA-PSS signature 
   generation should not also be used for other purposes.  For similar 
   reasons, one RSA key pair should always be used with the same 
   RSASSA-PSS parameters.  Likewise, an RSA key pair used for RSAES-
   OAEP key transport should not also be used for other purposes.  For 
   similar reasons, one RSA key pair should always be used with the 
   same RSAES-OAEP parameters. 
Schaad, Kaliski & Housley                            Page 20 

    
   This specification requires implementations to support the SHA-1 
   one-way hash function for interoperability, but support for other 
   one-way hash function is permitted.  At the time of this writing, 
   the best (known) collision attacks against SHA-1 are generic attacks 
   with complexity 2^80, where 80 is one-half the bit length of the 
   hash value.  In general, when a one-way hash function is used with a 
   digital signature scheme, a collision attack is easily translated 
   into a signature forgery.  Therefore, the use of SHA-1 in a digital 
   signature scheme provides a security level of no more than 80 bits.  
   If a greater level of security is desired, then a secure one-way 
   hash function with a longer hash value is needed.  SHA-256, SHA-384, 
   and SHA-512 are reasonable choices [SHA2]. 
    
   The metrics for choosing a one-way hash function for use in digital 
   signatures do not directly apply to the RSAES-OAEP key transport 
   algorithm, since a collision attack on the one-way hash function 
   does not directly translate into an attack on the key transport 
   algorithm, unless the encoding parameters P varies (in which case a 
   collision the hash value for different encoding parameters might be 
   exploited). 
    
   Nevertheless, for consistency with the practice for digital 
   signature schemes, and in case the encoding parameters P is not the 
   empty string, it is recommended that the same rule of thumb be 
   applied to selection of a one-way hash function for use with RSAES-
   OAEP.  That is, the one-way hash function should be selected so that 
   the bit length of the hash value is at least twice as long as the 
   desired security level in bits. 
    
   The key size selected impacts the strength achieved when 
   implementing cryptographic services.  Thus, selection of appropriate 
   key sizes is critical to implementing appropriate security.  A 1024-
   bit RSA public key and SHA-1 both provide a security level of about 
   80 bits.  In [GUIDE], the National Institute of Standards and 
   Technology (NIST) suggest that a security level of 80 bits is 
   adequate for the protection of sensitive information until 2015.  
   This recommendation is likely to be revised based on recent 
   advances, and the revised recommendation is expected to be more 
   conservative, suggesting that a security level of 80 bits is 
   adequate for the protection of sensitive information until 2010.  If 
   a security level greater than 80 bits is needed, then a longer RSA 
   public key and a secure one-way hash function with a longer hash 
   value are needed.  SHA-224, SHA-256, SHA-384, and SHA-512 are 
   reasonable choices for such a one-way hash function and, for this 
   reason, the algorithm identifiers for these one-way hash functions 
   are included in the ASN.1 module in section 6. 
    
   Current implementations MUST support 1024-bit RSA public key sizes.  
   Before the end of 2007, implementations SHOULD support RSA public 
   key sizes of at least 2048 bits and SHOULD support SHA-256.  This 

Schaad, Kaliski & Housley                            Page 21 

   requirement is intended to allow adequate time for users to deploy 
   the stronger digital signature capability by 2010. 
    
   When using RSASSA-PSS, the same one-way hash function should be 
   employed for the hashAlgorithm and the maskGenAlgorithm, but it is 
   not required.  Using the same one-way hash function helps with 
   security analysis, and it reduces implementation complexity. 
   When using RSAES-OAEP, the same one-way hash function should be 
   employed for the hashFunc and the maskGenFunc, but it is not 
   required. In each case, using the same one-way hash function helps 
   with security analysis, and it reduces implementation complexity. 
    
9  IANA Considerations 
    
   Within the certificates and CRLs, algorithms are identified by 
   object identifiers.  All of the object identifiers used in this 
   document were assigned in Public-Key Cryptography Standards (PKCS) 
   documents or by the National Institute of Standards and Technology 
   (NIST).  No further action by the IANA is necessary for this 
   document or any anticipated updates. 

10  Author Addresses 
    
   Russell Housley 
   Vigil Security, LLC 
   918 Spring Knoll Drive 
   Herndon, VA 20170 
   USA 
   housley@vigilsec.com 
    
   Burt Kaliski 
   RSA Laboratories 
   174 Middlesex Turnpike 
   Bedford, MA 01730 
   USA 
   bkaliski@rsasecurity.com 
    
   Jim Schaad 
   Soaring Hawk Consulting 
   PO Box 675 
   Gold Bar, WA 98251 
   USA 
   jimsch@exmsft.com 

11  Full Copyright Statement 
    
   Copyright (C) The Internet Society (2004). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
Schaad, Kaliski & Housley                            Page 22 

   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. 
   In addition, the ASN.1 modules presented in Section 5 may be used in 
   whole or in part without inclusion of the copyright notice. However, 
   this document itself may not be modified in any way, such as by 
   removing the copyright notice or references to the Internet Society 
   or other Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process shall be 
   followed, or as required to translate it into languages other than 
   English. 
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. This 
   document and the information contained herein is provided on an "AS 
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    

Schaad, Kaliski & Housley                            Page 23