< draft-ietf-pkix-sha2-dsa-ecdsa-05.txt   draft-ietf-pkix-sha2-dsa-ecdsa-06.txt >
PKIX Working Group Q. Dang (NIST)
Internet Draft S. Santesson (Microsoft)
Intended Category: Standards Track K. Moriarty (RSA)
D. Brown (Certicom Corp.)
Expires: April 30, 2009 T. Polk (NIST)
October 30, 2008
Internet X.509 Public Key Infrastructure: Additional
Algorithms and Identifiers for DSA and ECDSA
<draft-ietf-pkix-sha2-dsa-ecdsa-05.txt>
Status of this Memo 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
By submitting this Internet-Draft, each author represents Internet X.509 Public Key Infrastructure:
that any applicable patent or other IPR claims of which he Additional Algorithms and Identifiers for DSA and ECDSA
or she is aware have been or will be disclosed, and any of <draft-ietf-pkix-sha2-dsa-ecdsa-06.txt>
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Status of this Memo
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 This Internet-Draft is submitted to IETF in full
six months and may be updated, replaced, or obsoleted by conformance with the provisions of BCP 78 and BCP
other documents at any time. It is inappropriate to use 79.
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 Internet-Drafts are working documents of the
http://www.ietf.org/ietf/1id-abstracts.txt Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may
also distribute working documents as Internet-
Drafts.
The list of Internet-Draft Shadow Directories can be Internet-Drafts are draft documents valid for a
accessed at http://www.ietf.org/shadow.html. 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".
Copyright Notice The list of current Internet-Drafts can be
accessed at http://www.ietf.org/ietf/1id-
abstracts.txt
Copyright (C) The IETF Trust (2008). The list of Internet-Draft Shadow Directories can
be accessed at http://www.ietf.org/shadow.html.
Abstract Copyright Notice
This document supplements RFC 3279. It specifies algorithm Copyright (c) 2009 IETF Trust and the persons
identifiers and ASN.1 encoding rules for the Digital identified as the document authors. All rights
Signature Algorithm (DSA) and Elliptic Curve Digital reserved.
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", This document is subject to BCP 78 and the IETF
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", Trust's Legal Provisions Relating to IETF
and "OPTIONAL" in this document are to be interpreted as Documents
described in [RFC 2119]. (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.
Table of Contents Abstract
1. Introduction...................................................2 This document supplements RFC 3279. It specifies
2. One-way Hash Functions.........................................3 algorithm identifiers and ASN.1 encoding rules for
3. Signature Algorithms...........................................4 the Digital Signature Algorithm (DSA) and Elliptic
3.1 DSA Signature Algorithm..................................4 Curve Digital Signature Algorithm (ECDSA) digital
3.2 ECDSA Signature Algorithm................................6 signatures when using SHA-224, SHA-256, SHA-384 or
4. ASN.1 Module...................................................7 SHA-512 as hashing algorithm. This specification
5. Security Considerations........................................8 applies to the Internet X.509 Public Key
6. References....................................................10 Infrastructure (PKI) when digital signatures are
6.1 Normative references:...................................10 used to sign certificates and certificate
6.2 Informative references..................................11 revocation lists (CRLs).
7. Authors' Addresses............................................11
8. IANA Considerations...........................................12
9. Intellectual Property.........................................12
10.Copyright Statement...........................................13
1. Introduction 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].
This specification supplements [RFC 3279], "Algorithms and Identifiers Table of Contents
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.660] encoding rules for DSA and ECDSA
digital signatures in certificates and CRLs when using one of the SHA-2
hash algorithms (SHA-224, SHA-256, SHA-384, and SHA-512) as the hash
algorithm.
This specification defines the contents of the signatureAlgorithm, 1. Introduction.............................................3
signatureValue and signature fields within Internet X.509 certificates 2. One-way Hash Functions...................................3
and CRLs when these objects are signed using DSA or ECDSA with a SHA-2 3. Signature Algorithms.....................................4
hash algorithm. These fields are more fully described in [RFC 5280]. 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
This document profiles material presented in the ''Secure Hash Standard 1. Introduction
'' [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 This specification supplements [RFC 3279],
used with SHA-1 are specified in [RFC 3279]. Algorithm identifiers and "Algorithms and Identifiers for the Internet X.509
encoding rules for RSA when used with SHA-2 are specified in [RFC 4055]. 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.
2. One-way Hash Functions 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 section identifies four additional hash algorithms for use with DSA This document profiles material presented in the
and ECDSA in the Internet X.509 certificate and CRL profile [RFC 5280]. "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].
SHA-224, SHA-256, SHA-384, and SHA-512 produce a 224-bit, 256-bit, 384- Algorithm identifiers and encoding rules for RSA,
bit and 512-bit "hash" of the input respectively and are fully described DSA and ECDSA when used with SHA-1 are specified
in the Federal Information Processing Standard 180-3 [FIPS 180-3]. in [RFC 3279]. Algorithm identifiers and encoding
rules for RSA when used with SHA2 hash algorithms
are specified in [RFC 4055].
The listed one-way hash functions are identified by the following object 2. One-way Hash Functions
identifiers (OIDs):
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) This section identifies four additional hash
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) algorithms for use with DSA and ECDSA in the
4 } Internet X.509 certificate and CRL profile [RFC
5280].
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) SHA-224, SHA-256, SHA-384, and SHA-512 produce a
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 224-bit, 256-bit, 384-bit and 512-bit "hash" of
1 } the input respectively and are fully described in
the Federal Information Processing Standard 180-3
[FIPS 180-3].
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) The listed one-way hash functions are identified
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) by the following object identifiers (OIDs):
2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha224 OBJECT IDENTIFIER ::= { joint-
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) iso-itu-t(2) country(16) us(840)
3 } organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 4 }
When one of these OIDs appears in an AlgorithmIdentifier, all id-sha256 OBJECT IDENTIFIER ::= { joint-
implementations MUST accept both NULL and absent parameters as legal and iso-itu-t(2) country(16) us(840)
equivalent encodings. organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
3. Signature Algorithms id-sha384 OBJECT IDENTIFIER ::= { joint-
iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
Certificates and CRLs conforming to [RFC 5280] may be signed with any id-sha512 OBJECT IDENTIFIER ::= { joint-
public key signature algorithm. The certificate or CRL indicates the iso-itu-t(2) country(16) us(840)
algorithm through an identifier, which appears in the signatureAlgorithm organization(1) gov(101) csor(3)
field within the Certificate or CertificateList. This algorithm nistalgorithm(4) hashalgs(2) 3 }
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.
Signature algorithms are always used in conjunction with a one-way hash When one of these OIDs appears in an
function. This section identifies OIDs for DSA and ECDSA with SHA-224, AlgorithmIdentifier, all implementations MUST
SHA-256, SHA-384, and SHA-512. The contents of the parameters component accept both NULL and absent parameters as legal
for each signature algorithm vary; details are provided for each and equivalent encodings.
algorithm.
The data to be signed (e.g., the one-way hash function output value) is 3. Signature Algorithms
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. Certificates and CRLs conforming to [RFC 5280] may
Entities that validate ECDSA signatures MUST support SHA-224 and SHA-256 be signed with any public key signature algorithm.
and should support SHA-384 and SHA-512. 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.
3.1 DSA Signature Algorithm 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 DSA is defined in the Digital Signature Standard (DSS) [FIPS 186-3]. The data to be signed (e.g., the one-way hash
DSA was developed by the U.S. Government, and can be used in conjunction function output value) is formatted for the
with a SHA2 one-way hash function such as SHA-224 or SHA-256. DSA is signature algorithm to be used. Then, a private
fully described in [FIPS 186-3]. 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].
[FIPS 186-3] specifies four size-choices for a DSA key pair of the form Entities that validate DSA signatures MUST support
(public key size, private key size) in bits. The four choices are (1024, SHA-224 and SHA-256. Entities that validate ECDSA
160), (2048, 224), (2048, 256), and (3072, 256). More information can be signatures MUST support SHA-224 and SHA-256 and
found in [FIPS 186-3]. For the remainder of this specification, each and should support SHA-384 and SHA-512.
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 3.1 DSA Signature Algorithm
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.
When SHA-224 is used, the OID is: 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].
id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) [FIPS 186-3] specifies four size-choices for a DSA
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) key pair of the form (public key size, private key
id-dsa-with-sha2(3) 1 } 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.
When SHA-256 is used, the OID is: 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.
id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) When SHA-224 is used, the OID is:
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
The(3072, 256) DSA key pair provides 128 bits of security and provides id-dsa-with-sha224 OBJECT IDENTIFIER ::= {
the most security among all the four sizes of DSA key pairs. More joint-iso-ccitt(2) country(16) us(840)
information on security strength assessments of DSA and other organization(1) gov(101) csor(3) algorithms(4)
cryptographic algorithms can be found in [SP 800-57]. A digital id-dsa-with-sha2(3) 1 }.
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 a DSA key pair of the size (3072, 256) 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 When SHA-256 is used, the OID is:
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 id-dsa-with-sha256 OBJECT IDENTIFIER ::= {
completeness, this information is repeated below: joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }.
When signing, the DSA algorithm generates two values commonly referred The DSA key pair of 3072 bits provides 128 bits of
to as r and s. To easily transfer these two values as one signature, security and provides the most security among all
they SHALL be ASN.1 encoded using the following ASN.1 structure: 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].
Dss-Sig-Value ::= SEQUENCE { When the id-dsa-with-sha224 or id-dsa-with-sha256
r INTEGER, algorithm identifier appears in the algorithm
s INTEGER 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.
The DSA parameters in the subjectPublicKeyInfo field of the certificate Encoding rules for DSA signature values are
of the issuer SHALL apply to the verification of the signature. specified in [RFC 3279]. For completeness, this
information is repeated below:
3.2 ECDSA Signature Algorithm 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:
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in, Dss-Sig-Value ::= SEQUENCE {
"Public Key Cryptography for the Financial Services Industry: The r INTEGER,
Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. The ASN.1 s INTEGER
OIDs used to specify that an ECDSA signature was generated using SHA224, }.
SHA256, SHA384 or SHA 512 are respectively:
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) The DSA parameters in the subjectPublicKeyInfo
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } field of the certificate of the issuer SHALL apply
to the verification of the signature.
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3.2 ECDSA Signature Algorithm
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) The Elliptic Curve Digital Signature Algorithm
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } (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-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } iso(1) member-body(2) us(840) ansi-X9-
62(10045) signatures(4) ecdsa-with-SHA2(3) 1
}
When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as iso(1) member-body(2) us(840) ansi-X9-
an AlgorithmIdentifier, the encoding MUST omit the parameters field. 62(10045) signatures(4) ecdsa-with-SHA2(3) 2
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 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
explicitly, using the OIDs specified above, when encoding ECDSA/SHA-2 iso(1) member-body(2) us(840) ansi-X9-
signatures in certificates and CRLs. 62(10045) signatures(4) ecdsa-with-SHA2(3) 3
}
Conforming client implementations that process ECDSA signatures with any ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
of the SHA-2 hash algorithms when processing certificates and CRLs MUST iso(1) member-body(2) us(840) ansi-X9-
recognize the corresponding OIDs specified above. 62(10045) signatures(4) ecdsa-with-SHA2(3) 4
}
[X9.62] has defined additional OIDs for the ECDSA signature algorithm. 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.
Encoding rules for ECDSA signature values are specified in [RFC 3279]. Conforming CA implementations MUST specify the
For completeness, this information is repeated below: hash algorithm explicitly, using the OIDs
specified above, when encoding ECDSA/SHA2
signatures in certificates and CRLs.
When signing, the ECDSA algorithm generates two values commonly referred Conforming client implementations that process
to as r and s. To easily transfer these two values as one signature, ECDSA signatures with any of the SHA-2 hash
they MUST be ASN.1 encoded using the following ASN.1 structure: algorithms when processing certificates and CRLs
MUST recognize the corresponding OIDs specified
above.
Ecdsa-Sig-Value ::= SEQUENCE { [X9.62] has defined additional OIDs for the ECDSA
r INTEGER, signature algorithm.
s INTEGER
}
The elliptic curve parameters in the subjectPublicKeyInfo field of the Encoding rules for ECDSA signature values are
certificate of the issuer MUST be applied to the verification of the specified in [RFC 3279]. For completeness, this
signature. The subjectPublicKeyInfo field must be compliant with information is repeated below:
requirements for Subject Public Key Information field in [Elliptic
Curve].
4. ASN.1 Module 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:
DEFINITIONS EXPLICIT TAGS ::= Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}.
BEGIN 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
IMPORTS DEFINITIONS EXPLICIT TAGS ::=
NONE BEGIN
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) -- EXPORTS ALL --
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) -- All types and values defined in this module are
4 } -- exported for use in other ASN.1 modules.
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) IMPORTS
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) NONE
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha224 OBJECT IDENTIFIER ::= { joint-
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) iso-itu-t(2) country(16) us(840)
3 } organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 4 }
id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) id-sha256 OBJECT IDENTIFIER ::= { joint-
country(16) us(840) organization(1) gov(101) csor(3) iso-itu-t(2) country(16) us(840)
algorithms(4) id-dsa-with-sha2(3) 1 } organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) id-sha384 OBJECT IDENTIFIER ::= { joint-
country(16) us(840) organization(1) gov(101) csor(3) iso-itu-t(2) country(16) us(840)
algorithms(4) id-dsa-with-sha2(3) 2 } 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 }
ecdsa-with-SHA224 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) --
signatures(4) ecdsa-with-SHA2(3) 1 } --DSA with SHA-224 and SHA-256 signature algorithms
--
ecdsa-with-SHA256 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) id-dsa-with-sha224 OBJECT IDENTIFIER ::= {
signatures(4) ecdsa-with-SHA2(3) 2 } joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 1 }
ecdsa-with-SHA384 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) id-dsa-with-sha256 OBJECT IDENTIFIER ::= {
signatures(4) ecdsa-with-SHA2(3) 3 } joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
ecdsa-with-SHA512 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) --
signatures(4) ecdsa-with-SHA2(3) 4 } --ECDSA Signatures with SHA-2 Hashes, from X9.62
--
END -- Definitions ecdsa-with-SHA224 ::= { iso(1) member-
body(2) us(840) ansi-X9-62(10045)
signatures(4) ecdsa-with-SHA2(3) 1 }
5. Security Considerations ecdsa-with-SHA256 ::= { iso(1) member-
body(2) us(840) ansi-X9-62(10045)
signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 ::= { iso(1) member-
body(2) us(840) ansi-X9-62(10045)
signatures(4) ecdsa-with-SHA2(3) 3 }
This specification supplements [RFC 3279]. This document covers the DSA ecdsa-with-SHA512 ::= { iso(1) member-
and ECDSA algorithms with SHA2 hash functions and the associated body(2) us(840) ansi-X9-62(10045)
considerations. signatures(4) ecdsa-with-SHA2(3) 4 }
The appropriate use of the hash functions in terms of the algorithm END -- Definitions
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 5. Security Considerations
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].
The one-way hash algorithms discussed in this document, SHA-224, SHA- This specification supplements [RFC 3279]. This
256, SHA-384, and SHA-512 each have a recommended lifetime when used in document covers the DSA and ECDSA algorithms with
combination with a digital signature algorithm. NIST provides SHA2 hash functions and the associated
information on the appropriate time periods for which each combination considerations.
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 The appropriate use of the hash functions in terms
management to be used by both developers and system administrators. The of the algorithm strengths and expected time
document covers the aspects of key management from algorithm selection frames for secure use as defined by NIST can be
and key sizes with associated key usage period to key usage (preventing found in Special Publications (SPs) 800-78-1 [SP
key overlap), the compromise of keys and keying material, and key 800-78-1], 800-57 [SP 800-57] and 800-107 [SP 800-
destruction. Specific guidelines are offered for key usage periods such 107].
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 FIPS 186-3 fully specifies the DSA digital
combined hash algorithms and digital signature algorithms for specific signature algorithm and defines security
key types, but differentiates some security requirements between digital requirements for the DSA and ECDSA digital
signature and authentication keys. 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].
The recommendation for the size of digital signature keys and key The one-way hash algorithms discussed in this
management keys is more restrictive than that of authentication keys, document, SHA-224, SHA-256, SHA-384, and SHA-512
because they are used to protect data for longer periods of time. 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].
Therefore, the transition dates to larger key sizes are earlier in The Special Publication 800-57 also provides
general. 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.
Guidelines for the protection of domain parameters, initialization NIST Special Publication 800-78-1 also lists time
vectors (IVs), and per message secret numbers for use with digital frames for the use of combined hash algorithms and
signature algorithms, DSA and ECSDA are provided in [FIPS 186-3]. An digital signature algorithms for specific key
assurance of integrity should be obtained prior to using all keying types, but differentiates some security
material for the generation of digital signatures using DSA and ECDSA. requirements between digital signature and
Recommendation for Obtaining Assurances for Digital Signature authentication keys. The recommendation for the
Applications can be found in [SP 800-89]. The purpose of this is to size of digital signature keys and key management
ensure the keying material is in the proper format, the domain keys is more restrictive than that of
parameters are valid, the possession of the private key, the validity of authentication keys, because they are used to
the public key, and that the request is coming from an authorized protect data for longer periods of time.
source. 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
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 Certificate Authorities (CAs) that issue
ECDSA algorithms for key generation SHOULD adhere to the recommended certificates using the DSA and ECDSA algorithms
security guidelines for key management in the NIST Special Publication for key generation SHOULD adhere to the
800-57. When signing a digital signature certificate, a CA should use recommended security guidelines for key management
the same or greater size hash function than the hash function in the in the NIST Special Publication 800-57. When
digital signature algorithm in the certificate. 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. References
6.1 Normative references: 6.1 Normative References
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC 2119] Bradner, S., "Key Words for
Requirement Levels", RFC 2119, March 1997. Use in RFCs to Indicate
Requirement Levels", RFC 2119,
March 1997.
[RFC 3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC 3279] Bassham, L., Polk, W., and R.
Identifiers for the Internet X.509 Public Key Housley, "Algorithms and
Infrastructure Certificate and Certificate Revocation Identifiers for the Internet
List (CRL) Profile", RFC 3279, April 2002. 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. [RFC 5280] Cooper, D., Santesson, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Farrell, S., Boeyen, S.
Infrastructure Certificate and Certificate Revocation Housley, R., and W. Polk,
List (CRL) Profile", RFC 5280, May 2008. "Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List
(CRL) Profile", RFC 5280, May
2008.
[X9.62] X9.62-2005, "Public Key Cryptography for the Financial [X9.62] X9.62-2005, "Public Key
Services Industry: The Elliptic Curve Digital Signature Cryptography for the Financial
Standard (ECDSA)", November, 2005. Services Industry: The
Elliptic Curve Digital
Signature Standard (ECDSA)",
November, 2005.
[Elliptic Curve]Turner S., Brown D., Yiu K., Housley R., and Polk W., [Elliptic] Turner S., Brown D., Yiu K.,
"Elliptic Curve Cryptography Subject Public Key Housley R., and Polk W.,
Information" draft-ietf-pkix-ecc-subpubkeyinfo-08.txt "Elliptic Curve Cryptography
(work in progress), September 2008. 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 180-3] Federal Information Processing
(FIPS PUB) 180-3, Secure Hash Standard (SHS), October Standards Publication (FIPS
2008. PUB) 180-3, Secure Hash
Standard (SHS), October 2008.
[FIPS 186-3] Federal Information Processing Standards Publication [FIPS 186-3] Federal Information Processing
(FIPS PUB) 186-3, Digital Signature Standard (DSS), Standards Publication (FIPS
(draft) 13 March 2006. PUB) 186-3, Digital Signature
Standard (DSS), (draft)
November 2008.
6.2 Informative references [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.
[SP 800-107] Q. Dang, NIST, "Recommendation for Applications Using 6.2 Informative References
Approved Hash Algorithms", (draft) July 2008.
[SP 800-78-1] W. Timothy Polk, Donna, F. Dodson, William E. Burr, [SP 800-107] Quynh Dang, NIST,
NIST, "Cryptographic Standards and Key Sizes for "Recommendation for
Personal Identity Verification", August 2007. Applications Using Approved
Hash Algorithms", February
2009.
[SP 800-57] Elaine Barker, William Barker, William E. Burr, NIST, [SP 800-78-1] W. Timothy Polk, Donna, F.
"Recommendation for Key Management", August 2005. Dodson, William E. Burr, NIST,
"Cryptographic Standards and
Key Sizes for Personal
Identity Verification", August
2007.
[SP 800-89] Elaine Barker, NIST, "Recommendation for Obtaining [SP 800-57] Elaine Barker, William Barker,
Assurances for Digital Signature Applications", William E. Burr, NIST,
November 2006. "Recommendation for Key
Management", August 2005.
[SP 800-90] Elaine Barker, John Kelsey, NIST, ''Recommendation for [SP 800-89] Elaine Barker, NIST,
Random Number Generation Using Deterministic Random Bit "Recommendation for Obtaining
Generators'', March 2007. Assurances for Digital
Signature Applications",
November 2006.
[RFC 4055] Schaad, J., Kaliski, B., and Housley, R., "Additional [SP 800-90] Elaine Barker, John Kelsey,
Algorithms and Identifiers for RSA Cryptography for use NIST, ''Recommendation for
in the Internet X. 509 Public Key Infrastructure Random Number Generation Using
Certificate and Certificate Revocation List (CRL) Deterministic Random Bit
Profile", RFC 4055, June 2005. Generators'', March 2007.
7. Authors' Addresses [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.
Quynh Dang 7. Authors' Addresses
NIST Quynh Dang
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
Email: quynh.dang@nist.gov NIST
Stefan Santesson 100 Bureau Drive, Stop 8930
Microsoft Gaithersburg, MD 20899-8930
Tuborg Boulevard 12 USA
2900 Hellerup
Denmark
EMail: stefans@microsoft.com
Kathleen M. Moriarty Email: quynh.dang@nist.gov
RSA, The Security Division of EMC
174 Middlesex Turnpike
Bedford, MA 01730
Email: kathleen.moriarty@rsa.com
Daniel R. L. Brown Kathleen M. Moriarty
Certicom Corp.
5520 Explorer Drive
Mississaug, ON L4W 5L1
Email: dbrown@certicom.com
Tim Polk RSA, The Security Division of EMC
NIST 174 Middlesex Turnpike
100 Bureau Drive, Stop 8930 Bedford, MA 01730
Gaithersburg, MD 20899-8930
USA
Email: tim.polk@nist.gov
8. IANA Considerations Email: Moriarty_Kathleen@emc.com
Stefan Santesson
This document has no actions for IANA. EMail: stefans@exmsft.com
9. Intellectual Property Daniel R. L. Brown
The IETF takes no position regarding the validity or scope of any Certicom Corp.
Intellectual Property Rights or other rights that might be claimed to 5520 Explorer Drive
pertain to the implementation or use of the technology described in this Mississaug, ON L4W 5L1
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Email: dbrown@certicom.com
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Tim Polk
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10.Copyright Statement NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
Copyright (C) The IETF Trust (2008). Email: tim.polk@nist.gov
This document is subject to the rights, licenses and restrictions 8. IANA Considerations
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document has no actions for IANA.
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
 End of changes. 123 change blocks. 
425 lines changed or deleted 564 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/