PKIX Working Group R. Housley
Internet-Draft Vigil Security
January 2005
Additional Algorithms and Identifiers
for use of Elliptic Curve Cryptography with PKIX
(Explicit Identification of One-Way Hash Functions)
<draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Abstract
Dan Brown from Certicom has submitted a specification for Additional
Algorithms and Identifiers for use of Elliptic Curve Cryptography
with PKIX. This document proposes a different approach for
identifying the one-way hash function used with the ECDSA signature
algorithm.
Housley [Page 1]
Internet-Draft January 2005
1. Introduction
RFC 3279 [N1] specifies the conventions for using many algorithms
with certificates and CRLs. When ECDSA is used with SHA-1, RFC 3279
says that the following object identifier ought to be employed:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
Dan Brown from Certicom has submitted a specification for Additional
Algorithms and Identifiers for use of Elliptic Curve Cryptography
with PKIX [I1]. In his document, Dan proposes a different approach
for identifying the one-way hash function used with the ECDSA
signature algorithm.
The following new object identifier identifies the one-way hash
function is the one recommended for the public key size:
ecdsa-with-Recommended OBJECT IDENTIFIER ::= { id-ecSigType recommended(2) }
In this case, the recommended one-way hash functions are given in the
draft revision of X9.62 [I2]. The appropriate one-way has function
is selected from SHA-1, SHA-224, SHA-256, SHA-384, and 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 one-way hash function output bit length is greater than the bit
length of n, the order of the base point G.
This approach leads to potential ambiguity in the future. The
concern is that additional one-way hash functions will be added to
the "approved" set.
The alternative is to explicitly identify the one-way hash function
that is employed with ECDSA.
1.1. Conventions Used In This Document
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 [N2].
1.2. Abstract Syntax Notation
All X.509 certificate [N3] extensions are defined using ASN.1
[N4][7].
Housley [Page 2]
Internet-Draft January 2005
2. ECDSA with Explicit Identification of the One-Way Hash Function
To avoid potential ambiguity, this specification provides algorithm
identifiers for ECDSA with the following one-way hash functions:
SHA-224, SHA-256, SHA-384, and SHA-512. Note that the algorithm
identifier for ECDSA with SHA-1 is already provided in RFC 3279 [N1].
These algorithm identifiers have already been assigned by ANSI X9F1.
They are:
ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 }
id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
id-ecdsa-with-SHA2 OBJECT IDENTIFIER ::= {id-ecSigType 3}
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 1}
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 2}
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 3}
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 4}
3. Security Considerations
This specification does not constrain the size of public keys or
their parameters for use in the Internet PKI. However, the key size
selected impacts the strength achieved when implementing
cryptographic services. Selection of appropriate key sizes is
critical to implementing appropriate security.
This specification does not identify particular elliptic curves for
use in the Internet PKI. However, the particular curve selected
impact the strength of the digital signatures. Some curves are
cryptographically stronger than others!
In general, use of "well-known" curves, such as the "named curves"
from ANSI X9.62 [I2], is a sound strategy. For additional
information, refer to X9.62 Appendix H.1.3, "Key Length
Considerations" and Appendix A.1, "Avoiding Cryptographically Weak
Keys".
4. IANA Considerations
Certificate extensions and extended key usage values are identified
by object identifiers (OIDs). The OIDs used in this document are
copied from the draft revision to X9.62 [I2]. These OIDs were
assigned by ANSI X9F1. No further action by the IANA is necessary
for this document or any anticipated updates.
Housley [Page 3]
Internet-Draft January 2005
5. References
Normative and informative references are provided.
5.1. Normative References
[N1] Polk, W., Housley, R., and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002.
[N2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[N3] ITU-T. Recommendation X.509: The Directory - Authentication
Framework. 2000.
[N4] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[N5] CCITT. Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988.
5.2. Informative References
[I1] Brown, D., "Additional Algorithms and Identifiers for use of
Elliptic Curve Cryptography with PKIX", Internet-Draft,
July 2004, work in progress.
<draft-ietf-pkix-ecc-pkalgs-00.txt>
[I2] American National Standard for Financial Services. ANSI
X9.62-1998, Public Key Cryptography for the Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm. 1998.
(An update is in the works.)
Housley [Page 4]
Internet-Draft January 2005
6. ASN.1 Module
ECDSA-Algorithm-Identifiers
{ TBD }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 }
id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
id-ecdsa-with-SHA2 OBJECT IDENTIFIER ::= {id-ecSigType 3}
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 1}
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 2}
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 3}
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {id-ecdsa-with-SHA2 4}
END
7. IPR Considerations
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Housley [Page 5]
Internet-Draft January 2005
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.
8. Author's Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
housley@vigilsec.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
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.
Housley [Page 6]