draft-ietf-pkix-rsa-pkalgs-00.txt

PKIX的RFC英文文档

                           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 used





Housley & 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 specified



Housley & 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 field



Housley & 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 2002


4.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, and



Housley & Kaliski                                              [Page 11]

INTERNET DRAFT                                             December 2002