[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5758

  PKIX Working Group                    Q. Dang     (NIST)
  Internet Draft                        S. Santesson
  Intended Category: Standards Track    K. Moriarty  (RSA)
                                 D. Brown (Certicom Corp.)
                                        T. Polk     (NIST)
                                            March 6, 2009
  Expires: September 6, 2009
  
  
  
  
             Internet X.509 Public Key Infrastructure:
        Additional Algorithms and Identifiers for DSA and ECDSA
              <draft-ietf-pkix-sha2-dsa-ecdsa-06.txt>
  
  
       Status of this Memo
  
       This Internet-Draft is submitted to IETF in full
       conformance with the provisions of BCP 78 and BCP
       79.
  
       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-Draft Shadow Directories can
       be accessed at http://www.ietf.org/shadow.html.
  
       Copyright Notice
  
       Copyright (c) 2009 IETF Trust and the persons
       identified as the document authors. All rights
       reserved.
  
       This document is subject to BCP 78 and the IETF
       Trust's Legal Provisions Relating to IETF
       Documents
  
  Dang, et al.  Expires September 6, 2009          [Page 1]
  

  Internet-Draft          DSA/ECDSA              March 2009
  
  
       (http://trustee.ietf.org/license-info) in effect
       on the date of publication of this document.
       Please review these documents carefully, as they
       describe your rights and restrictions with respect
       to this document.
  
  
       Abstract
  
       This document supplements RFC 3279. It specifies
       algorithm identifiers and ASN.1 encoding rules for
       the Digital Signature Algorithm (DSA) and Elliptic
       Curve Digital Signature Algorithm (ECDSA) digital
       signatures when using SHA-224, SHA-256, SHA-384 or
       SHA-512 as hashing algorithm. This specification
       applies to the Internet X.509 Public Key
       Infrastructure (PKI) when digital signatures are
       used to sign certificates and certificate
       revocation lists (CRLs).
  
       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].
  
  
          Table of Contents
  
  
      1. Introduction.............................................3
      2. One-way Hash Functions...................................3
      3. Signature Algorithms.....................................4
       3.1 DSA Signature Algorithm................................5
       3.2 ECDSA Signature Algorithm..............................7
      4. ASN.1 Module.............................................8
      5. Security Considerations.................................10
      6. References..............................................12
       6.1   Normative references:...............................12
       6.2   Informative references:.............................13
      7. Authors' Addresses......................................14
      8. IANA Considerations.....................................15
  
  
  
  
  
  
  
  Dang, et al.    Expires September 6, 2009           [Page 2]
  

  Internet-Draft          DSA/ECDSA                 March 2009
  
  
  1. Introduction
  
  
       This specification supplements [RFC 3279],
       "Algorithms and Identifiers for the Internet X.509
       Public Key Infrastructure Certificate and
       Certificate Revocation List (CRL) Profile" and
       extends the list of algorithms defined for use in
       the Internet PKI. This document specifies
       algorithm identifiers and ASN.1 [X.690] encoding
       rules for DSA and ECDSA digital signatures in
       certificates and CRLs when using one of the SHA2
       hash algorithms (SHA-224, SHA-256, SHA-384, and
       SHA-512) as the hash algorithm.
  
       This specification defines the contents of the
       signatureAlgorithm, signatureValue and signature
       fields within Internet X.509 certificates and CRLs
       when these objects are signed using DSA or ECDSA
       with a SHA2 hash algorithm. These fields are more
       fully described in [RFC 5280].
  
       This document profiles material presented in the
       "Secure Hash Standard" [FIPS 180-3], "Public Key
       Cryptography for the Financial Services Industry:
       The Elliptic Curve Digital Signature Standard
       (ECDSA)" [X9.62], and the "Digital Signature
       Standard" [FIPS 186-3].
  
       Algorithm identifiers and encoding rules for RSA,
       DSA and ECDSA when used with SHA-1 are specified
       in [RFC 3279]. Algorithm identifiers and encoding
       rules for RSA when used with SHA2 hash algorithms
       are specified in [RFC 4055].
  
  2. One-way Hash Functions
  
       This section identifies four additional hash
       algorithms for use with DSA and ECDSA in the
       Internet X.509 certificate and CRL profile [RFC
       5280].
  
  
  
  
  
  
  
  
  
  
  
  Dang, et al.    Expires September 6, 2009         [Page 3]
  

  Internet-Draft          DSA/ECDSA               March 2009
  
  
       SHA-224, SHA-256, SHA-384, and SHA-512 produce a
       224-bit, 256-bit, 384-bit and 512-bit "hash" of
       the input respectively and are fully described in
       the Federal Information Processing Standard 180-3
       [FIPS  180-3].
  
       The listed one-way hash functions are identified
       by the following object identifiers (OIDs):
  
           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 }
  
       When one of these OIDs appears in an
       AlgorithmIdentifier, all implementations MUST
       accept both NULL and absent parameters as legal
       and equivalent encodings.
  
  3. Signature Algorithms
  
       Certificates and CRLs conforming to [RFC 5280] may
       be signed with any public key signature algorithm.
       The certificate or CRL indicates the algorithm
       through an identifier, which appears in the
       signatureAlgorithm field within the Certificate or
       CertificateList. This algorithm identifier is an
       OID and has optionally associated parameters. This
       section denotes algorithm identifiers and
       parameters that MUST be used in the
       signatureAlgorithm field in a Certificate or
       CertificateList.
  
  
  
  
  Dang, et al.    Expires September 6, 2009          [Page 4]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
  
  
       Signature algorithms are always used in
       conjunction with a one-way hash function. This
       section identifies OIDs for DSA and ECDSA with
       SHA-224, SHA-256, SHA-384, and SHA-512. The
       contents of the parameters component for each
       signature algorithm vary; details are provided for
       each algorithm.
  
       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., DSA 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. More detail on how digital
       signatures are generated can be found in [FIPS
       186-3].
  
       Entities that validate DSA signatures MUST support
       SHA-224 and SHA-256. Entities that validate ECDSA
       signatures MUST support SHA-224 and SHA-256 and
       should support SHA-384 and SHA-512.
  
       3.1  DSA Signature Algorithm
  
       The DSA is defined in the Digital Signature
       Standard (DSS) [FIPS 186-3]. DSA was developed by
       the U.S. Government, and can be used in
       conjunction with a SHA2 one-way hash function such
       as SHA-224 or SHA-256. DSA is fully described in
       [FIPS 186-3].
  
       [FIPS 186-3] specifies four size-choices for a DSA
       key pair of the form (public key size, private key
       size) in bits. The four choices are (1024, 160),
       (2048, 224), (2048, 256), and (3072, 256). More
       information can be found in [FIPS 186-3]. For the
       remainder of this specification, each and every
       key pair of the DSA key pairs is referred to by
       the size of its public key.
  
       DSA key pairs of 1024 and 2048 bits may be used
       with SHA-224. DSA key pairs of any of the four
       sizes may use SHA-256. The following are the OIDs
       of the DSA digital signature algorithm when used
       with SHA-224 or SHA-256.
  
  
  Dang, et al.    Expires September 6, 2009           [Page 5]
  

  Internet-Draft          DSA/ECDSA                 March 2009
  
  
       When SHA-224 is used, the OID is:
  
           id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  {
           joint-iso-ccitt(2) country(16) us(840)
           organization(1) gov(101) csor(3) algorithms(4)
           id-dsa-with-sha2(3) 1 }.
  
       When SHA-256 is used, the OID is:
  
           id-dsa-with-sha256 OBJECT IDENTIFIER  ::=  {
           joint-iso-ccitt(2) country(16) us(840)
           organization(1) gov(101) csor(3) algorithms(4)
           id-dsa-with-sha2(3) 2 }.
  
       The DSA key pair of 3072 bits provides 128 bits of
       security and provides the most security among all
       the four sizes of DSA key pairs. More information
       on security strength assessments of DSA and other
       cryptographic algorithms can be found in [SP 800-
       57]. A digital signature algorithm has the same
       security strength as its asymmetric key algorithm
       like DSA or ECDSA only if its hashing algorithm
       has at least the same security strength as the
       asymmetric key algorithm. Therefore, a 128-bit
       security strength hashing algorithm which is SHA-
       256 will be sufficient to build a 128-bit security
       strength DSA digital signature algorithm when the
       DSA key pair of 3072 bits is used. Therefore, it
       is only needed to specify DSA with SHA-224 and
       SHA-256 because SHA-256 provides sufficient
       security for using with any DSA key pair of any of
       the four size choices. More information on
       security strengths of the hash functions SHAs
       specified in [FIPS 180-3] and the digital
       signature algorithms specified in [FIPS 186-3] can
       be found in [SP 800-107] and [SP 800-57].
  
       When the id-dsa-with-sha224 or id-dsa-with-sha256
       algorithm identifier appears in the algorithm
       field as an AlgorithmIdentifier, the encoding
       SHALL omit the parameters field. That is, the
       AlgorithmIdentifier SHALL be a SEQUENCE of one
       component, the OID id-dsa-with-sha224 or id-dsa-
       with-sha256.
  
       Encoding rules for DSA signature values are
       specified in [RFC 3279]. For completeness, this
       information is repeated below:
  
  
  
  Dang, et al.    Expires September 6, 2009          [Page 6]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
       When signing, the DSA algorithm generates two
       values commonly referred to as r and s. To easily
       transfer these two values as one signature, they
       SHALL be ASN.1 encoded using the following ASN.1
       structure:
  
            Dss-Sig-Value  ::=  SEQUENCE  {
                                            r  INTEGER,
                                            s  INTEGER
                                          }.
  
       The DSA parameters in the subjectPublicKeyInfo
       field of the certificate of the issuer SHALL apply
       to the verification of the signature.
  
       3.2  ECDSA Signature Algorithm
  
       The Elliptic Curve Digital Signature Algorithm
       (ECDSA) is defined in, "Public Key Cryptography
       for the Financial Services Industry: The Elliptic
       Curve Digital Signature Standard (ECDSA)" [X9.62].
       The ASN.1 OIDs used to specify that an ECDSA
       signature was generated using SHA-224, SHA-256,
       SHA-384 or SHA-512 are respectively:
  
           ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) ansi-X9-
           62(10045) signatures(4) ecdsa-with-SHA2(3) 1
           }
  
           ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) ansi-X9-
           62(10045) signatures(4) ecdsa-with-SHA2(3) 2
           }
  
           ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) ansi-X9-
           62(10045) signatures(4) ecdsa-with-SHA2(3) 3
           }
  
           ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) ansi-X9-
           62(10045) signatures(4) ecdsa-with-SHA2(3) 4
           }
  
       When the ecdsa-with-SHA224, ecdsa-with-SHA256,
       ecdsa-with-SHA384 or ecdsa-with-SHA512 algorithm
       identifier appears in the algorithm field as an
       AlgorithmIdentifier, the encoding MUST omit the
       parameters field. That is, the AlgorithmIdentifier
  
  Dang, et al.    Expires September 6, 2009          [Page 7]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
       SHALL be a SEQUENCE of one component, the OID
       ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-
       SHA384 or ecdsa-with-SHA512.
  
       Conforming CA implementations MUST specify the
       hash algorithm explicitly, using the OIDs
       specified above, when encoding ECDSA/SHA2
       signatures in certificates and CRLs.
  
       Conforming client implementations that process
       ECDSA signatures with any of the SHA-2 hash
       algorithms when processing certificates and CRLs
       MUST recognize the corresponding OIDs specified
       above.
  
       [X9.62] has defined additional OIDs for the ECDSA
       signature algorithm.
  
       Encoding rules for ECDSA signature values are
       specified in [RFC 3279]. For completeness, this
       information is repeated below:
  
       When signing, the ECDSA algorithm generates two
       values commonly referred to as r and s. To easily
       transfer these two values as one signature, they
       MUST be ASN.1 encoded using the following ASN.1
       structure:
  
            Ecdsa-Sig-Value  ::=  SEQUENCE {
                                            r  INTEGER,
                                            s  INTEGER
                                           }.
  
       The elliptic curve parameters in the
       subjectPublicKeyInfo field of the certificate of
       the issuer MUST be applied to the verification of
       the signature. The subjectPublicKeyInfo field must
       be compliant with requirements for Subject Public
       Key Information field in [Elliptic].
  
  4. ASN.1 Module
  
       DEFINITIONS EXPLICIT TAGS ::=
  
       BEGIN
  
       -- EXPORTS ALL --
       -- All types and values defined in this module are
       -- exported for use in other ASN.1 modules.
  
  
  Dang, et al.    Expires September 6, 2009          [Page 8]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
       IMPORTS
  
       NONE
  
           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 }
  
       --
       --DSA with SHA-224 and SHA-256 signature algorithms
       --
  
  
           id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  {
           joint-iso-ccitt(2) country(16) us(840)
           organization(1) gov(101) csor(3) algorithms(4)
           id-dsa-with-sha2(3) 1 }
  
           id-dsa-with-sha256 OBJECT IDENTIFIER  ::=  {
           joint-iso-ccitt(2) country(16) us(840)
           organization(1) gov(101) csor(3) algorithms(4)
           id-dsa-with-sha2(3) 2 }
  
      --
       --ECDSA Signatures with SHA-2 Hashes, from X9.62
       --
  
           ecdsa-with-SHA224  ::=  { iso(1) member-
           body(2) us(840) ansi-X9-62(10045)
           signatures(4) ecdsa-with-SHA2(3) 1 }
  
           ecdsa-with-SHA256  ::=  { iso(1) member-
           body(2) us(840) ansi-X9-62(10045)
           signatures(4) ecdsa-with-SHA2(3) 2 }
  
  Dang, et al.    Expires September 6, 2009          [Page 9]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
  
           ecdsa-with-SHA384  ::=  { iso(1) member-
           body(2) us(840) ansi-X9-62(10045)
           signatures(4) ecdsa-with-SHA2(3) 3 }
  
           ecdsa-with-SHA512  ::=  { iso(1) member-
           body(2) us(840) ansi-X9-62(10045)
           signatures(4) ecdsa-with-SHA2(3) 4 }
  
  
       END -- Definitions
  
  
  
  5. Security Considerations
  
  
       This specification supplements [RFC 3279]. This
       document covers the DSA and ECDSA algorithms with
       SHA2 hash functions and the associated
       considerations.
  
       The appropriate use of the hash functions in terms
       of the algorithm strengths and expected time
       frames for secure use as defined by NIST can be
       found in Special Publications (SPs) 800-78-1 [SP
       800-78-1], 800-57 [SP 800-57] and 800-107 [SP 800-
       107].
  
       FIPS 186-3 fully specifies the DSA digital
       signature algorithm and defines security
       requirements for the DSA and ECDSA digital
       signature algorithms; details can be found in
       [FIPS 186-3]. ECDSA is fully specified in [X9.62].
       [FIPS 186-3] also specifies three types of
       elliptic curves for use in conjunction with one of
       the described hash functions: curves over prime
       fields, curves over binary fields, and Koblitz
       curves (anomalous binary curves). FIPS 186-3
       provides a table listing the uses and time periods
       for each algorithm and key size combinations for
       various applications. The DSA and ECDSA private
       keys must be generated from pseudorandom functions
       whose security strengths meet or exceed the
       desired security strengths for the digital
       signature algorithms. Guidelines on building these
       NIST-approved pseudorandom functions can be found
       in SP 800-90 [SP 800-90]. The hash functions must
       meet or exceed the desired security strengths of
       the digital signature algorithms. More guidelines
       can be found in SP 800-57 [SP 800-57] and SP 800-
       107 [SP 800-107].
  
  Dang, et al.   Expires September 6, 2009          [Page 10]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
  
       The one-way hash algorithms discussed in this
       document, SHA-224, SHA-256, SHA-384, and SHA-512
       each have a recommended lifetime when used in
       combination with a digital signature algorithm.
       NIST provides information on the appropriate time
       periods for which each combination should be used
       based upon the security needs of the service and
       information being protected in NIST Special
       Publication 800-57. A table outlines the year in
       which NIST deems it is no longer safe to use
       specific combinations of key lengths and
       algorithms of various strengths for RSA, DSA, and
       ECDSA. NIST also provides Recommendation for using
       NIST-approved hash algorithms in the digital
       signature applications in [SP 800-107].
  
       The Special Publication 800-57 also provides
       guidelines for key management to be used by both
       developers and system administrators. The document
       covers the aspects of key management from
       algorithm selection and key sizes with associated
       key usage period to key usage (preventing key
       overlap), the compromise of keys and keying
       material, and key destruction. Specific guidelines
       are offered for key usage periods such as the
       lifetime of a private signature key may be shorter
       than the lifetime of the public verification key
       for practical applications. The specification also
       provides recommendations on the number of years
       various key types should be used such as public
       and private signature keys, public and private
       authentication keys, etc.
  
       NIST Special Publication 800-78-1 also lists time
       frames for the use of combined hash algorithms and
       digital signature algorithms for specific key
       types, but differentiates some security
       requirements between digital signature and
       authentication keys. The recommendation for the
       size of digital signature keys and key management
       keys is more restrictive than that of
       authentication keys, because they are used to
       protect data for longer periods of time.
       Therefore, the transition dates to larger key
       sizes are earlier in general. Guidelines for the
       protection of domain parameters, initialization
       vectors (IVs), and per message secret numbers for
       use with digital signature algorithms, DSA and
       ECSDA are provided in [FIPS 186-3]. An assurance
  
  Dang, et al.   Expires September 6, 2009          [Page 11]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
       of integrity should be obtained prior to using all
       keying material for the generation of digital
       signatures using DSA and ECDSA. Recommendation for
       Obtaining Assurances for Digital Signature
       Applications can be found in [SP 800-89]. The
       purpose of this is to ensure the keying material
       is in the proper format, the domain parameters are
       valid, the possession of the private key, the
       validity of the public key, and that the request
       is coming from an authorized source.
  
       Certificate Authorities (CAs) that issue
       certificates using the DSA and ECDSA algorithms
       for key generation SHOULD adhere to the
       recommended security guidelines for key management
       in the NIST Special Publication 800-57. When
       signing a digital signature certificate, a CA
       should use the same or greater size hash function
       than the hash function in the digital signature
       algorithm in the certificate.
  
  
  6. References
  
  6.1   Normative References
  
             [RFC 2119]   Bradner, S., "Key Words for
                          Use in RFCs to Indicate
                          Requirement Levels", RFC 2119,
                          March 1997.
  
             [RFC 3279]   Bassham, L., Polk, W., and R.
                          Housley, "Algorithms and
                          Identifiers for the Internet
                          X.509 Public Key
                          Infrastructure Certificate and
                          Certificate Revocation List
                          (CRL) Profile", RFC 3279,
                          April 2002.
  
             [RFC 5280]   Cooper, D., Santesson, S.,
                          Farrell, S., Boeyen, S.
                          Housley, R., and W. Polk,
                          "Internet X.509 Public Key
                          Infrastructure Certificate and
                          Certificate Revocation List
                          (CRL) Profile", RFC 5280, May
                          2008.
  
  
  
  Dang, et al.   Expires September 6, 2009          [Page 12]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
             [X9.62]      X9.62-2005, "Public Key
                          Cryptography for the Financial
                          Services Industry: The
                          Elliptic Curve Digital
                          Signature Standard (ECDSA)",
                          November, 2005.
  
             [Elliptic]   Turner S., Brown D., Yiu K.,
                          Housley R., and Polk W.,
                          "Elliptic Curve Cryptography
                          Subject Public Key
                          Information" draft-ietf-pkix-
                          ecc-subpubkeyinfo-11.txt (work
                          in progress), December 2008.
  
             [FIPS 180-3] Federal Information Processing
                          Standards Publication (FIPS
                          PUB) 180-3, Secure Hash
                          Standard (SHS), October 2008.
  
             [FIPS 186-3] Federal Information Processing
                          Standards Publication (FIPS
                          PUB) 186-3, Digital Signature
                          Standard (DSS), (draft)
                          November 2008.
  
             [X.690]      ITU-T Recommendation X.660
                          Information Technology -
                          ASN.1 encoding rules:
                          Specification of Basic
                          Encoding Rules (BER),
                          Canonical Encoding Rules (CER)
                          and Distinguished Encoding
                          Rules (DER), 1997.
  
  
  
  6.2   Informative References
  
              [SP 800-107] Quynh Dang, NIST,
                          "Recommendation for
                          Applications Using Approved
                          Hash Algorithms", February
                          2009.
  
              [SP 800-78-1] W. Timothy Polk, Donna, F.
                          Dodson, William E. Burr, NIST,
                          "Cryptographic Standards and
                          Key Sizes for Personal
  
  
  Dang, et al.   Expires September 6, 2009          [Page 13]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
                          Identity Verification", August
                          2007.
  
              [SP 800-57]  Elaine Barker, William Barker,
                          William E. Burr, NIST,
                          "Recommendation for Key
                          Management", August 2005.
  
              [SP 800-89]  Elaine Barker, NIST,
                          "Recommendation for Obtaining
                          Assurances for Digital
                          Signature Applications",
                          November 2006.
  
              [SP 800-90]  Elaine Barker, John Kelsey,
                          NIST, ''Recommendation for
                          Random Number Generation Using
                          Deterministic Random Bit
                          Generators'', March 2007.
  
              [RFC 4055]   Schaad, J., Kaliski, B., and
                          Housley, R., "Additional
                          Algorithms and Identifiers for
                          RSA Cryptography for use in
                          the Internet X. 509 Public Key
                          Infrastructure Certificate and
                          Certificate Revocation List
                          (CRL) Profile", RFC 4055, June
                          2005.
  
  
  
  
  7. Authors' Addresses
  
  Quynh Dang
  
  NIST
  100 Bureau Drive, Stop 8930
  Gaithersburg, MD 20899-8930
  USA
  
  Email: quynh.dang@nist.gov
  
  
  Kathleen M. Moriarty
  
  RSA, The Security Division of EMC
  174 Middlesex Turnpike
  Bedford, MA 01730
  
  Email: Moriarty_Kathleen@emc.com
  
  
  
  Dang, et al.   Expires September 6, 2009          [Page 14]
  

  Internet-Draft          DSA/ECDSA                March 2009
  
  
  Stefan Santesson
  
  EMail: stefans@exmsft.com
  
  
  Daniel R. L. Brown
  
  Certicom Corp.
  5520 Explorer Drive
  Mississaug, ON L4W 5L1
  
  Email: dbrown@certicom.com
  
  
  Tim Polk
  
  NIST
  100 Bureau Drive, Stop 8930
  Gaithersburg, MD 20899-8930
  USA
  
  Email: tim.polk@nist.gov
  
  
  
  
  8. IANA Considerations
  
  
     This document has no actions for IANA.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Dang, et al.   Expires September 6, 2009       [Page 15]
  

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/