PKIX Working Group Q. Dang (NIST)
Internet Draft S. Santesson (Microsoft)
Intended Category: Standards Track K. Moriarty (MIT/LL)
Expires: December 2006 D. Brown (Certicom Corp.)
T. Polk (NIST)
June 16, 2006
Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for
DSA and ECDSA
<draft-ietf-pkix-sha2-dsa-ecdsa-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author
represents that any applicable patent or other
IPR claims of which he or she is aware have
been or will be disclosed, and any of 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 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
This Internet-Draft will expire on December
16, 2006.
Dang Expires December 2006 [Page 1]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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, 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 list (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 Algorithm...............................4
3.1. DSA Signature Algorithm......................5
3.2. ECDSA Signature Algorithm....................6
3.2.1. ECDSA with SHA-2 Hash Algorithms........7
3.2.2. ECDSA with Recommended Hash Algorithm...8
3.2.3. ECDSA With Specified Hash Algorithm.....8
4. ASN.1 Module......................................9
5. Security Considerations..........................10
6. References.......................................12
6.1. Normative references:.......................12
6.2. Informative references......................13
7. Authors' Addresses...............................14
8. Acknowledgements.................................14
9. IANA Considerations..............................15
10. Disclaimer of Validity..........................15
11. Copyright Statement.............................15
Dang Expires December 2006 [Page 2]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
1. Introduction
This specification supplements [RFC 3279], "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 SHA-224, SHA-256, SHA-
384, or SHA-512 as the hashing 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 SHA-2 hash
algorithm. These fields are more fully described in [RFC
3280].
This document profiles material presented in the "Secure
Hash Standard" [FIPS 180-2], "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 SHA-2 are specified in [RFC 4055].
2. One-way Hash Functions
This section identifies four additional hash algorithms
for use with DSA and ECDSA and the Internet X.509
certificate and CRL profile [RFC 3280].
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-2 [FIPS 180-2].
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 }
Dang Expires December 2006 [Page 3]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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 }
All implementations MUST accept both NULL and absent
parameters as legal and equivalent encodings.
3. Signature Algorithm
Certificates and CRLs conforming to [RFC 3280] 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.
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
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.
Dang Expires December 2006 [Page 4]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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 three choices for sizes of DSA key
pairs. The biggest size key pair consists of 3072-bit
public key and 256-bit private key, and it provides 128
bits of security. 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 will be sufficient to build a 128-bit security
strength DSA digital signature algorithm when a pair of
3072-bit DSA public key and 256-bit DSA private key is
used. Therefore, it is only needed to specify DSA with
SHA-224 and SHA-256 because SHA-256 provides 128 bits of
security. The ASN.1 OIDs used to tie DSA with SHA-224 and
SHA-256 follows:
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) 1}
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:
When signing, the DSA algorithm generates two values
commonly referred to as r and s. To easily transfer these
Dang Expires December 2006 [Page 5]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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]. [X9.62] provides alternative
mechanisms for specifying the hash algorithm used in the
signature generation process. Three methods are specified
in this document.
1) The signature OID may explicitly identify the hash
algorithm, as specified in Section 3.2.1 below.
2) The signature OID may specify that the signer used the
recommended hash algorithm for a given key size, as
described in Section 3.2.2. A verifier infers from the
size of the public key which hash algorithm was used.
3) The signature OID may indicate that the hash algorithm
is specified as a parameter of the signature OID. The
verifier identifies the appropriate hash algorithm
according to the hash algorithm OID in the parameters
field.
Conforming CA implementations MUST specify the hash
algorithm explicitly, using the OIDs specified in Section
3.2.1, when encoding ECDSA/SHA-2 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 in Section 3.2.1. Conforming
client implementations MAY also recognize the signature
OIDs specified in Sections 3.2.2 and 3.2.3.
Dang Expires December 2006 [Page 6]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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. Encoding rules for
ECDSA public keys are specified in [RFC 3279].
3.2.1. ECDSA with SHA-2 Hash Algorithms
The ASN.1 OIDs used to specify that an ECDSA signature was
generated using SHA224, SHA256, SHA384 or SHA 512
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 SHALL be a SEQUENCE of one component:
the OID: ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-
SHA384 or ecdsa-with-SHA512.
Dang Expires December 2006 [Page 7]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
3.2.2. ECDSA with Recommended Hash Algorithm
The following object identifier identifies the hash
function to be used for message digesting implicitly,
based on the size of the signer's public key:
ecdsa-with-Recommended OBJECT IDENTIFIER ::= {
id-ecSigType recommended(2) }
The recommended hash functions are given in the draft
revision of X9.62, and is determined as follows. Among
the hash functions SHA-1, SHA-224, SHA-256, SHA-384, SHA-
512, the recommended one has the largest bit size that
does not require bit truncation during the signing
process. Bit truncation occurs when the hash output
bitlength is greater than the bit length of n, the order
of the base point G. (Note: even if bit trunctation does
not occur, modular reduction can occur.)
Conforming CA implementations MUST NOT specify the ecdsa-
with-Recommended OID when encoding certificates and CRLs.
To maximize interoperability, conforming client
implementations MAY recognize the ecdsa-with-Recommended
OID when processing certificates and CRLs.
3.2.3. ECDSA With Specified Hash Algorithm
The following object identifier identifies the hash
function to be used for message digesting is the one
specified in the parameters field of the algorithm
identifier:
ecdsa-with-Specified OBJECT IDENTIFIER ::= {
id-ecSigType specified(3) }
For signatures are generated using one of the SHA-2 hash
algorithms, the parameters field would contain the
appropriate OID from Section 2.
Conforming CA implementations MUST NOT specify the ecdsa-
with-Specified OID when encoding certificates and CRLs.
To maximize interoperability, conforming client
implementations MAY recognize the ecdsa-with-Specified OID
when processing certificates and CRLs.
Dang Expires December 2006 [Page 8]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
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.
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 }
--
-- 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}
ecdsa-with-SHA384 ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3)
3}
Dang Expires December 2006 [Page 9]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
ecdsa-with-SHA512 ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3)
4}
ecdsa-with-Recommended OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 signatures(4)
2 }
ecdsa-with-Specified OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 signatures(4) 3 }
--
-- DSA with SHA-224 and SHA-256 signature algorithms
--
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}
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}
END -- Definitions
5. Security Considerations
This specification supplements [RFC 3279]. The Security
Considerations section of that document applies, but is
specific to the RSA algorithm and this document covers the
DSA and ECDSA algorithms and the associated
considerations.
The appropriate use of the hash functions in terms of the
algorithm strength and expected time frames for secure use
as defined by NIST can be found in Special Publications
800-78 [SP 800-78] and 800-57 [SP 800-57].
NIST recommends three elliptic curves: curves over prime
fields, curves over binary fields, and Koblitz curves, to
be used in conjunction with one of the described hash
functions for security reasons in [FIPS 186-3]. [FIPS 186-
3] provides a table listing the uses and time periods for
each algorithm and key size combinations for various
Dang Expires December 2006 [Page 10]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
applications. For further details, see the referenced
document.
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.
The 800-57 publication discusses the "best practices" 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 also lists time frames for
the use of combined hash algorithms and digital signature
algorithms for specific key types, including the
O Personal Identity Verification (PIV) authentication
key,
O Card authentication key,
O Digital signature key, and
O Key management key.
Specific requirements on the PIV can be found in [FIPS
201].
Dang Expires December 2006 [Page 11]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
The recommendation for the size of digital signature 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 of
integrity should be obtained prior to using all keying
material for the generation of digital signatures using
DSA and ECDSA. 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.
Algorithm implementations MUST follow the appropriate
specification to ensure the generation of secure keys.
The SHA-2 algorithm is fully defined in [FIPS 180-2].
[FIPS 186-3] defines the requirements for the digital
signature standard specifying the requirements for both
DSA and ECDSA. ECDSA is fully specified in [ANS X9.62].
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. A
CA should use the same size or greater hash function than
what is used when generating keys for subscriber signature
certificates.
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
Dang Expires December 2006 [Page 12]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[RFC 3280] Housley, R., Polk, W., Ford, W., and D.
Solo, "Internet X.509 Public Key
Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280,
April 2002.
[X9.62] X9.62-2005, "Public Key Cryptography for
the Financial Services Industry: The
Elliptic Curve Digital Signature Standard
(ECDSA)", November, 2005.
[FIPS 180-2] Federal Information Processing Standards
Publication (FIPS PUB) 182-2, Secure Hash
Standard (SHS), 1 August 2002.
[FIPS 186-3] Draft Federal Information Processing
Standards Publication (FIPS PUB) 186-3,
Digital Signature Standard (DSS), 13 March
2006.
6.2. Informative references
[SP 800-78] W. Timothy Polk, Donna, F. Dodson, William
E. Burr, NIST, "Cryptographic Algorithms
and Key Sizes for Personal Identity
Verification", January 2005.
[SP 800-57] Elaine Barker, William Barker, William E.
Burr, NIST, "Recommendation for Key
Management", August 2005.
[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.
[FIPS 201] Federal Information Processing Standards
Publication (FIPS PUB) 201, Personal
Identity Verification (PIV) of Federal
Dang Expires December 2006 [Page 13]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
Employees and Contractors, 25 February
2005.
7. Authors' Addresses
Quynh Dang
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
Email: quynh.dang@nist.gov
Stefan Santesson
Microsoft
Tuborg Boulevard 12
2900 Hellerup
Denmark
EMail: stefans@microsoft.com
Kathleen M. Moriarty
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Email: moriarty@ll.mit.edu
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. Acknowledgements
This work was sponsored in part by the U.S. Air Force
under Air Force Contract Number F19628-00-C-0002.
Dang Expires December 2006 [Page 14]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
"Opinions, interpretations, conclusions, and
recommendations are those of the author and are not
necessarily endorsed by the United States Government."
9. IANA Considerations
None
10. Disclaimer of Validity
The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use
of the technology described in this 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 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 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.
11. Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Dang Expires December 2006 [Page 15]
Internet-Draft DSA/ECDSA Algorithm Identifiers May 2006
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF
ANY), THE INTERNET SOCIETY 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.
Expires December, 2006
Dang Expires December 2006 [Page 16]
