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]
