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

PKIX的RFC英文文档

                        { id-RSAES-OAEP,
                           { sha384Identifier,
                             mgf1SHA384Identifier,
                             pSpecifiedEmptyIdentifier  }  }

   rSAES-OAEP-SHA512-Identifier  AlgorithmIdentifier  ::=
                        { id-RSAES-OAEP,
                           { sha512Identifier,
                             mgf1SHA512Identifier,
                             pSpecifiedEmptyIdentifier  }  }


   -- ===================
   --   Main structures
   -- ===================

   -- Used in SubjectPublicKeyInfo of X.509 Certificate.

   RSAPublicKey  ::=  SEQUENCE  {
      modulus           INTEGER,    -- n
      publicExponent    INTEGER  }  -- e



Housley & Kaliski                                              [Page 17]

INTERNET DRAFT                                             December 2002


   -- 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  {
      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]   J. Jonsson, J., and B. Kaliski, "PKCS #1: RSA
              Cryptography Specifications Version 2.1", Internet-Draft,
              August 2002.  <draft-jonsson-pkcs1-v2dot1-00.txt>

   [PROFILE]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure: Certificate and CRL
              Profile", RFC 3280, April 2002.





Housley & Kaliski                                              [Page 18]

INTERNET DRAFT                                             December 2002


   [SHA2]     National Institute of Standards and Technology (NIST),
              FIPS 180-2: Secure Hash Standard, 1 August 2002.

   [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.

   [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



Housley & Kaliski                                              [Page 19]

INTERNET DRAFT                                             December 2002


   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.

   This specification requires implementation 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



Housley & Kaliski                                              [Page 20]

INTERNET DRAFT                                             December 2002


   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.

   This specification does not constrain the size of public keys or
   their parameters for use in the Internet PKI.  However, the key size
   selected impacts the strength achieved when implementing
   cryptographic services.  Selection of appropriate key sizes is
   critical to implementing appropriate security.  However, 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) suggests that a security level of 80 bits is adequate for the
   protection of sensitive information until 2015.  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.
   Again, SHA-256, SHA-384, and SHA-512 are reasonable choices for such
   a one-way hash function.  For this reason, the algorithm identifiers
   for these one-way hash functions are included in the ASN.1 module in
   section 5.

   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.  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.












Housley & Kaliski                                              [Page 21]

INTERNET DRAFT                                             December 2002


10  Author Addresses

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   [e-mail]

   Burt Kaliski
   RSA Laboratories
   174 Middlesex Turnpike
   Bedford, MA 01730
   USA
   [e-mail]

11  Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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
   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.






Housley & Kaliski                                              [Page 22]