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, implementations must also handle an   algorithm identifier parameters field which contains a NULL.   The AlgorithmIdentifier parameters field is OPTIONAL.  If present,   the parameters field must contain a NULL.  Implementations MUST   accept an AlgorithmIdentifiers with absent parameters as well as   AlgorithmIdentifiers with NULL parameters.  Within this   specification, there are many places where a NULL parameter is   REQUIRED.  To be clear, the following algorithm identifiers are usedHousley & Kaliski                                               [Page 6]INTERNET DRAFT                                             December 2002   when a NULL parameter MUST be present:      sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, 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, sha256Identifier,   sha384Identifier, or sha512Identifier, as specified in section 2.1.   Implementations MUST support the default value, sha1Identifier, and   implementations MAY support the other three values.   The following algorithm identifiers have been assigned for each of   these alternatives:      mgf1SHA1Identifier  AlgorithmIdentifier  ::=                           { id-mgf1, sha1Identifier }      mgf1SHA256Identifier  AlgorithmIdentifier  ::=                           { id-mgf1, sha256Identifier }      mgf1SHA384Identifier  AlgorithmIdentifier  ::=                           { id-mgf1, sha384Identifier }      mgf1SHA512Identifier  AlgorithmIdentifier  ::=                           { id-mgf1, sha512Identifier }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 specifiedHousley & Kaliski                                               [Page 7]INTERNET DRAFT                                             December 2002   in PKCS #1 version 2.1 [P1v2.1].  The four 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.  Conforming CAs   and applications MUST support RSASSA-PSS digital signatures using   SHA-1.  The other three one-way hash functions MAY also be supported.   Certificates and CRLs conforming to [PROFILE] may be signed with any   public key signature algorithm.  The certificate or CRL indicates the   algorithm through an algorithm identifier which appears in the   signatureAlgorithm field within the Certificate or CertificateList.   This algorithm identifier is an object identifier (OID) and optional   parameters.  Section 3.1 specifies the object identifier and   parameters for RSASSA-PSS digital signatures.   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 be present, and the parameters MUST employ the RSASSA-PSS-params   syntax.      id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }      RSASSA-PSS-params  ::=  SEQUENCE  {         hashAlgorithm      [0] HashAlgorithm DEFAULT                                   sha1Identifier,         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 fieldHousley & Kaliski                                               [Page 8]INTERNET DRAFT                                             December 2002         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.  It MUST be an algorithm identifier, and 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 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 a 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.  Implementations that         perform signature validation MUST recognize both the id-mgf1         and id-sha1 object identifiers as well as an absent         maskGenAlgorithm field as an indication that MGF1 with SHA-1         was used.      saltLength         The saltLength field is the octet length of the salt.  It MUST         be an integer.  For a given hashAlgorithm, the default 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 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.Housley & Kaliski                                               [Page 9]INTERNET DRAFT                                             December 2002         Implementations that perform signature validation MUST         recognize both a present 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,                              { 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.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 four 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.   Certificates and CRLs conforming to [PROFILE] may be signed with any   public key signature algorithm.  The certificate or CRL indicates the   algorithm through an algorithm identifier which appears in the   signatureAlgorithm field within the Certificate or CertificateList.   This algorithm identifier is an object identifier (OID) and optional   parameters.  Section 4.1 specifies the object identifier and   parameters for RSAES-OAEP key transport.Housley & Kaliski                                              [Page 10]INTERNET DRAFT                                             December 20024.1  RSAES-OAEP Public Keys   When RSAES-OAEP is used in an AlgorithmIdentifier, the parameters   MUST be present, and the parameters MUST employ the RSAES-OAEP-params   syntax.      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  }      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.         It MUST be an algorithm identifier, and 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, andHousley & Kaliski                                              [Page 11]INTERNET DRAFT                                             December 2002