summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5758.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5758.txt')
-rw-r--r--doc/rfc/rfc5758.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5758.txt b/doc/rfc/rfc5758.txt
new file mode 100644
index 0000000..55b0b05
--- /dev/null
+++ b/doc/rfc/rfc5758.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Q. Dang
+Request for Comments: 5758 NIST
+Updates: 3279 S. Santesson
+Category: Standards Track 3xA Security
+ISSN: 2070-1721 K. Moriarty
+ EMC
+ D. Brown
+ Certicom Corp.
+ T. Polk
+ NIST
+ January 2010
+
+
+ Internet X.509 Public Key Infrastructure:
+ Additional Algorithms and Identifiers for DSA and ECDSA
+
+Abstract
+
+ This document updates RFC 3279 to specify 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 the 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). This document
+ also identifies all four SHA2 hash algorithms for use in the Internet
+ X.509 PKI.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5758.
+
+
+
+
+
+
+
+
+
+
+Dang, et al. Standards Track [Page 1]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+ (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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Hash Functions ..................................................3
+ 3. Signature Algorithms ............................................3
+ 3.1. DSA Signature Algorithm ....................................4
+ 3.2. ECDSA Signature Algorithm ..................................4
+ 4. ASN.1 Module ....................................................5
+ 5. Security Considerations .........................................6
+ 6. References ......................................................6
+ 6.1. Normative References .......................................6
+ 6.2. Informative References .....................................7
+ 7. Acknowledgements ................................................7
+
+1. Introduction
+
+ 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 [RFC5280]. This document also identifies all
+ four SHA2 hash algorithms for use in the Internet X.509 PKI.
+
+ This document profiles material presented in the "Secure Hash
+ Standard" [FIPS180-3], "Public Key Cryptography for the Financial
+ Services Industry: The Elliptic Curve Digital Signature Standard
+ (ECDSA)" [X9.62], and the "Digital Signature Standard" [FIPS186-3].
+
+ This document updates RFC 3279 [RFC3279] Sections 2.1, 2.2.2, and
+ 2.2.3. Note that RFC 5480 [RFC5480] updates Sections 2.3.5, 3 (ASN.1
+ Module), and 5 (Security Considerations) of RFC 3279.
+
+
+
+
+
+Dang, et al. Standards Track [Page 2]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+ 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 [RFC2119].
+
+2. Hash Functions
+
+ This section identifies four additional hash algorithms for use with
+ DSA and ECDSA in the Internet X.509 certificate and CRL profile
+ [RFC5280]. 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 "Secure Hash Standard" [FIPS180-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.
+
+ Conforming certification authority (CA) implementations SHOULD use
+ SHA-224, SHA-256, SHA-384, or SHA-512 when generating certificates or
+ CRLs, but MAY use SHA-1 if they have a stated policy that requires
+ the use of this weaker algorithm.
+
+3. Signature Algorithms
+
+ This section identifies OIDs for DSA with SHA-224 and SHA-256 as well
+ as 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.
+
+
+
+
+
+Dang, et al. Standards Track [Page 3]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+3.1. DSA Signature Algorithm
+
+ The DSA is defined in the Digital Signature Standard (DSS)
+ [FIPS186-3]. DSA was developed by the U.S. Government, and can be
+ used in conjunction with a SHA2 hash function such as SHA-224 or
+ SHA-256. DSA is fully described in [FIPS186-3].
+
+ 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 }.
+
+ 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 [RFC3279].
+
+ Conforming CA implementations that generate DSA signatures for
+ certificates or CRLs MUST generate such DSA signatures in accordance
+ with all the requirements in Sections 4.1, 4.5, and 4.6 of
+ [FIPS186-3].
+
+ Conforming CA implementations that generate DSA signatures for
+ certificates or CRLs MAY generate such DSA signatures in accordance
+ with all the requirements and recommendations in [FIPS186-3], if they
+ have a stated policy that requires conformance to [FIPS186-3].
+
+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:
+
+
+
+
+
+
+
+Dang, et al. Standards Track [Page 4]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+ 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 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 SHA2 hash algorithms when processing certificates and CRLs
+ MUST recognize the corresponding OIDs specified above.
+
+ Encoding rules for ECDSA signature values are specified in RFC 3279
+ [RFC3279], Section 2.2.3, and RFC 5480 [RFC5480].
+
+ Conforming CA implementations that generate ECDSA signatures in
+ certificates or CRLs MUST generate such ECDSA signatures in
+ accordance with all the requirements specified in Sections 7.2 and
+ 7.3 of [X9.62] or with all the requirements specified in Section
+ 4.1.3 of [SEC1].
+
+ Conforming CA implementations that ECDSA signatures in certificates
+ or CRLs MAY generate such ECDSA signatures in accordance with all the
+ requirements and recommendations in [X9.62] or [SEC1] if they have a
+ stated policy that requires conformance to [X9.62] or [SEC1].
+
+4. ASN.1 Module
+
+ The OIDs of the SHA2 hash algorithms are in the RFC 4055 [RFC4055]
+ ASN.1 module and the OIDs for DSA with SHA-224 and SHA-256 as well as
+ ECDSA with SHA-224, SHA-256, SHA-384, and SHA-512 are defined in the
+ RFC 5480 [RFC5480] ASN.1 module.
+
+
+
+
+Dang, et al. Standards Track [Page 5]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+5. Security Considerations
+
+ NIST has defined appropriate use of the hash functions in terms of
+ the algorithm strengths and expected time frames for secure use in
+ Special Publications (SPs) 800-78-1 [SP800-78-1], 800-57 [SP800-57],
+ and 800-107 [SP800-107]. These documents can be used as guides to
+ choose appropriate key sizes for various security scenarios.
+
+ ANSI also provides security considerations for ECDSA in [X9.62].
+ These security considerations may be used as a guide.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3279] 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.
+
+ [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "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.
+
+ [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+ Polk, "Elliptic Curve Cryptography Subject Public Key
+ Information", RFC 5480, March 2009.
+
+ [RFC5280] 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.
+
+ [FIPS180-3] Federal Information Processing Standards Publication
+ (FIPS PUB) 180-3, Secure Hash Standard (SHS), October
+ 2008.
+
+ [FIPS186-3] Federal Information Processing Standards Publication
+ (FIPS PUB) 186-3, Digital Signature Standard (DSS), June
+ 2009.
+
+ [SEC1] Standards for Efficient Cryptography Group (SECG), SEC
+ 1: Elliptic Curve Cryptography, Version 2.0, 2009.
+
+
+
+Dang, et al. Standards Track [Page 6]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+ [X9.62] X9.62-2005, "Public Key Cryptography for the Financial
+ Services Industry: The Elliptic Curve Digital Signature
+ Standard (ECDSA)", November, 2005.
+
+6.2. Informative References
+
+ [SP800-107] Quynh Dang, NIST, "Recommendation for Applications Using
+ Approved Hash Algorithms", February 2009.
+
+ [SP800-78-1] W. Timothy Polk, Donna, F. Dodson, William E. Burr,
+ NIST, "Cryptographic Standards and Key Sizes for
+ Personal Identity Verification", August 2007.
+
+ [SP800-57] Elaine Barker, William Barker, William E. Burr, NIST,
+ "Recommendation for Key Management", August 2005.
+
+7. Acknowledgements
+
+ The authors of this document would like to acknowledge great inputs
+ for this document from Alfred Hoenes, Sean Turner, Katrin Hoeper, and
+ many others from IETF community. The authors also appreciate many
+ great revision suggestions from Russ Housley and Paul Hoffman.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dang, et al. Standards Track [Page 7]
+
+RFC 5758 DSA/ECDSA January 2010
+
+
+Authors' Addresses
+
+ Quynh Dang
+ NIST
+ 100 Bureau Drive, Stop 8930
+ Gaithersburg, MD 20899-8930
+ USA
+
+ EMail: quynh.dang@nist.gov
+
+
+ Stefan Santesson
+ 3xA Security (AAA-sec.com)
+ Bjornstorp 744
+ 247 98 Genarp
+ Sweden
+
+ EMail: sts@aaa-sec.com
+
+
+ Kathleen M. Moriarty
+ RSA, The Security Division of EMC
+ 174 Middlesex Turnpike
+ Bedford, MA 01730
+ USA
+
+ EMail: Moriarty_Kathleen@emc.com
+
+
+ Daniel R. L. Brown
+ Certicom Corp.
+ 5520 Explorer Drive
+ Mississaug, ON L4W 5L1
+ USA
+
+ EMail: dbrown@certicom.com
+
+
+ Tim Polk
+ NIST
+ 100 Bureau Drive, Stop 8930
+ Gaithersburg, MD 20899-8930
+ USA
+
+ EMail: tim.polk@nist.gov
+
+
+
+
+
+
+Dang, et al. Standards Track [Page 8]
+