PKIX Working Group L. Bassham (NIST)
Internet Draft D. Johnson (Certicom)
expires April 21, 1999 W. Polk (NIST)
October 21, 1999
Internet X.509 Public Key Infrastructure
Representation of Elliptic Curve Digital Signature Algorithm
(ECDSA) Keys and Signatures in Internet X.509 Public Key
Infrastructure Certificates
<draft-ietf-pkix-ipki-ecdsa-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459. In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm. This specification only addresses the format of ECDSA
keys and signatures. Please send comments on this document to the
ietf-pkix@imc.org mail list.
Bassham, Johnson & Polk [Page 1]
INTERNET DRAFT October 21, 1999
1 Executive Summary
This specification contains guidance on the use of the Internet
Public Key Infrastructure certificates to convey Elliptic Curve
Digital Signature Algorithm (ECDSA) keys. This specification is an
addendum to RFC 2459, "Internet Public Key Infrastructure: X.509
Certificate and CRL Profile". Implementations of this specification
must also conform to RFC 2459. Implementations of this specification
are not required to conform to other parts from that series.
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the
elliptic curve analog of the Digital Signature Algorithm (DSA). This
specification profiles the format and semantics of fields in X.509 V3
certificates containing ECDSA keys. The specification addresses the
subjectPublicKeyInfo field and the keyUsage extension.
2 Requirements and Assumptions
The goal is to augment the X.509 certificate profile presented in
Part 1 to facilitate the use and management of ECDSA keys for those
communities which use this algorithm.
2.1 Communication and Topology
This profile, as presented in Part 1 and augmented by this
specification, supports users without high bandwidth, real-time IP
connectivity, or high connection availability. In addition, the
profile allows for the presence of firewall or other filtered
communication.
This profile does not assume the deployment of an X.500 Directory
system. The profile does not prohibit the use of an X.500 Directory,
but other means of distributing certificates and certificate
revocation lists (CRLs) are supported.
2.2 Acceptability Criteria
The goal of the Internet Public Key Infrastructure (PKI) is to meet
the needs of deterministic, automated identification, authentication,
access control, and authorization functions. Support for these
services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as
policy data and certification path constraints.
The goal of this document is to profile ECDSA certificates,
specifying the contents and semantics of attributes which were not
fully specified by Part 1. If not specifically addressed by this
document, the contents and semantics of the fields and extensions
Bassham, Johnson & Polk [Page 2]
INTERNET DRAFT October 21, 1999
must be as described in Part 1.
2.3 User Expectations
Users of the Internet PKI are people and processes who use client
software and are the subjects named in certificates. These uses
include readers and writers of electronic mail, the clients for WWW
browsers, WWW servers, and the key manager for IPSEC within a router.
This profile recognizes the limitations of the platforms these users
employ and the sophistication/attentiveness of the users themselves.
This manifests itself in minimal user configuration responsibility
(e.g., root keys, rules), explicit platform usage constraints within
the certificate, certification path constraints which shield the user
from many malicious actions, and applications which sensibly automate
validation functions.
2.4 Administrator Expectations
As with users, the Internet PKI profile is structured to support the
individuals who generally operate Certification Authorities (CAs).
Providing administrators with unbounded choices increases the chances
that a subtle CA administrator mistake will result in broad
compromise or unnecessarily limit interoperability. This profile
defines the object identifiers and data formats that must be
supported to interpret ECDSA public keys.
3 ECDSA Algorithm Support
This section describes object identifiers and data formats which may
be used with PKIX certificate profile to describe X.509 certificates
containing an ECDSA public key or signed with ECDSA. Conforming CAs
are required to use the object identifiers and data formats when
issuing ECDSA certificates. Conforming applications shall recognize
the object identifiers and process the data formats when processing
such certificates.
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
the ANSI X9.62 standard [X9.62]. The ASN.1 object identifiers used
to identify the ECDSA algorithm are defined in the following arc:
ansi-X9-62 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) 10045 }
3.1 Subject Public Key Info
The certificate identifies the ECDSA algorithm, conveys optional
parameters, and specifies the ECDSA public key in the
subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a
Bassham, Johnson & Polk [Page 3]
INTERNET DRAFT October 21, 1999
SEQUENCE of an algorithm identifier and the subjectPublicKey field.
The certificate indicates the algorithm through an algorithm
identifier. This algorithm identifier consists of an object
identifier (OID) and optional associated parameters. Section 3.1.1
identifies the preferred OID and parameters for the ECDSA algorithm.
Conforming CAs shall use the identified OID when issuing certificates
containing public keys for the ECDSA algorithm. Conforming
applications supporting the ECDSA algorithm shall, at a minimum,
recognize the OID identified in section 3.1.1.
The certificate conveys the ECDSA public key through the
subjectPublicKey field. This subjectPublicKey field is a BIT STRING.
Section 3.1.2 specifies the method for encoding a ECDSA public key as
a BIT STRING. Conforming CAs shall encode the ECDSA public key as
described in Section 3.1.2 when issuing certificates containing
public keys for the ECDSA algorithm. Conforming applications
supporting the ECDSA algorithm shall decode the subjectPublicKey as
described in section 3.1.2 when the algorithm identifier is the one
presented in 3.1.1.
3.1.1 Algorithm Identifier and Parameters
When certificates contain an ECDSA public key, the id-ecPublicKey
algorithm identifier shall be used. The id-ecPublicKey algorithm
identifier is defined as follows:
id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 }
id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
ECDSA requires use of certain parameters with the public key. The
parameters may be inherited from the issuer, implicitly included
through reference to a "named curve," or explicitly included in the
certificate.
Parameters ::= CHOICE {
ecParameters ECParameters,
namedCurve CURVES.&id({CurveNames}),
implicitlyCA NULL }
When the parameters are inherited, the parameters field shall contain
implictlyCA, which is the ASN.1 value NULL. When parameters are
specified by reference, the parameters field shall contain the
namedCurve choice, which is an an object identifier. When the
parameters are explicitly included, they shall be encoded in the
ASN.1 structure ECParameters:
Bassham, Johnson & Polk [Page 4]
INTERNET DRAFT October 21, 1999
ECParameters ::= SEQUENCE {
version INTEGER { ecpVer1(1) } (ecpVer1),
-- version is always 1
fieldID FieldID { {FieldTypes} },
-- identifies the finite field over
-- which the curve is defined
curve Curve, -- coefficients a and b of the
-- elliptic curve
base ECPoint, -- specifies the base point P
-- on the elliptic curve
order INTEGER, -- the order n of the base point
cofactor INTEGER OPTIONAL,
... }
FieldElement ::= OCTET STRING
The value of FieldElement shall be the octet string representation of
a field element following the conversion routine in [X9.62, Section
4.3.1]
Curve ::= SEQUENCE {
a FieldElement,
b FieldElement,
seed BIT STRING OPTIONAL
}
ECPoint ::= OCTET STRING
The value of ECPoint shall be the octet string representation of an
elliptic curve point following the conversion routine in [X9.62,
Section 4.4.3.b]
The components of type ECParameters have the following meanings:
* version specifies the version number of the elliptic curve
parameters. It shall have the value 1 for this version of the
Standard. The notation above creates an INTEGER named ecpVer1 and
gives it a value of one. It is used to constrain version to a single
value.
* fieldID identifies the finite field over which the elliptic curve
is defined. Finite fields are represented by values of the
parameterized type FieldID, constrained to the values of the objects
defined in the information object set FieldTypes. Additional detail
regarding fieldID is provided below.
* curve specifies the coefficients a and b of the elliptic curve E.
Each coefficient shall be represented as a value of type
Bassham, Johnson & Polk [Page 5]
INTERNET DRAFT October 21, 1999
FieldElement, an OCTET STRING. seed is an optional parameter used to
derive the coefficients of a randomly generated elliptic curve.
* base specifies the base point P on the elliptic curve. The base
point shall be represented as a value of type ECPoint, an OCTET
STRING.
* order specifies the order n of the base point.
* cofactor is the integer h = #E(Fq)/n. Note: This optional parameter
is not used in ECDSA, except in parameter validation. Parameter
validation is not required by this specification. It is included for
compatibility with Elliptic Curve Key Agreement public key
parameters, and to support parameter validation.
The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
within a certificate where the parameters may be used. If the ECDSA
algorithm parameters are absent from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using
ECDSA, then the certificate issuer's ECDSA parameters apply to the
subject's ECDSA key. If the ECDSA algorithm parameters are absent
from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
the certificate using a signature algorithm other than ECDSA, then
clients shall not validate the certificate.
FieldID { FIELD-ID:IOSet } ::= SEQUENCE {
fieldType FIELD-ID.&id({IOSet}),
parameters FIELD-ID.&Type({IOSet}{@fieldType}) OPTIONAL
}
FieldTypes FIELD-ID ::= {
{ Prime-p IDENTIFIED BY prime-field } |
{ Characteristic-two IDENTIFIED BY characteristic-two-field },
...
}
FIELD-ID ::= TYPE-IDENTIFIER
FieldID is a parameterized type composed of two components, fieldType
and parameters. These components are specified by the fields &id and
&Type, which form a template for defining sets of information
objects, instances of the class FIELD-ID. This class is based on the
useful information object class TYPE-IDENTIFIER, described in X.681
Annex A. In an instance of FieldID, "fieldType" will contain an
object identifier value that uniquely identifies the type contained
in "parameters". The effect of referencing "fieldType" in both
components of the fieldID sequence is to tightly bind the object
identifier and its type.
Bassham, Johnson & Polk [Page 6]
INTERNET DRAFT October 21, 1999
The information object set FieldTypes is used as the single parameter
in a reference to type FieldID. FieldTypes contains two objects
followed by the extension marker ("..."). Each object, which
represents a finite field, contains a unique object identifier and
its associated type. The values of these objects define all of the
valid values that may appear in an instance of fieldID. The extension
marker allows backward compatibility with future versions of this
standard which may define objects to represent additional kinds of
finite fields.
The object identifier id-fieldType represents the root of a tree
containing the object identifiers of each field type. It has the
following value:
id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
The object identifiers prime-field and characteristic-two-field name
the two kinds of fields defined in this Standard. They have the
following values:
prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
Prime-p ::= INTEGER -- Field size p (p in bits)
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m (m in bits)
basis CHARACTERISTIC-TWO.&id({BasisTypes}),
parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
}
BasisTypes CHARACTERISTIC-TWO::= {
{ NULL IDENTIFIED BY gnBasis } |
{ Trinomial IDENTIFIED BY tpBasis } |
{ Pentanomial IDENTIFIED BY ppBasis },
...
}
Trinomial ::= INTEGER
Pentanomial ::= SEQUENCE {
k1 INTEGER,
k2 INTEGER,
k3 INTEGER
}
CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
Bassham, Johnson & Polk [Page 7]
INTERNET DRAFT October 21, 1999
The object identifier id-characteristic-two-basis represents the root
of a tree containing the object identifiers for each type of basis
for the characteristic-two finite fields. It has the following value:
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(1) }
The object identifiers gnBasis, tpBasis and ppBasis name the three
kinds of basis for characteristic-two finite fields defined by
[X9.62]. They have the following values:
gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
3.1.2 Encoding of ECDSA Public Keys
The elliptic curve public key (an ECPoint which is an OCTET STRING)
is mapped to a subjectPublicKey (a BIT STRING) as follows: the most
significant bit of the OCTET STRING becomes the most significant bit
of the BIT STRING, etc.; the least significant bit of the OCTET
STRING becomes the least significant bit of the BIT STRING.
3.1.3 Key Usage Extension in ECDSA certificates
The key usage extension may optionally appear in certificates which
convey an ECDSA public key. If a certificate containing an ECDSA
public key includes the keyUsage extension, only the following values
may be asserted:
digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.
The keyCertSign and cRLSign values may only be asserted if the
basicConstraints extension is present and cA is TRUE.
3.2 Representation of ECDSA Signatures
When used to sign certificates, CRLs, or PKI messages, the ECDSA
shall be used with the SHA-1 hash algorithm. The ASN.1 object
identifier used to identify the ECDSA algorithm with SHA-1 shall be:
id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
When the ecdsa-with-SHA1 algorithm identifier is used in the SIGNED
Bassham, Johnson & Polk [Page 8]
INTERNET DRAFT October 21, 1999
parameterized TYPE (e.g., in the signature on a certificate or CRL)
it shall have NULL parameters. The ECDSA parameters in the
certificate of the issuer shall apply to the verification of the
signature. When signing, the ECDSA algorithm generates two values.
These values are 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:
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
4 ASN.1 Module
ANSI-X9-62 { iso(1) member-body(2) us(840) 10045 module(4) 1 }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS All;
-- IMPORTS None;
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
FieldID { FIELD-ID:IOSet } ::= SEQUENCE { -- Finite field
fieldType FIELD-ID.&id({IOSet}),
parameters FIELD-ID.&Type({IOSet}{@fieldType})
}
FieldTypes FIELD-ID ::= {
{ Prime-p IDENTIFIED BY prime-field } |
{ Characteristic-two IDENTIFIED BY characteristic-two-field },
...
}
FIELD-ID ::= TYPE-IDENTIFIER -- ISO/IEC 8824-2:1995(E), Annex A
id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime
Characteristic-two ::= SEQUENCE {
Bassham, Johnson & Polk [Page 9]
INTERNET DRAFT October 21, 1999
m INTEGER, -- Field size 2^m
basis CHARACTERISTIC-TWO.&id({BasisTypes}),
parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
}
BasisTypes CHARACTERISTIC-TWO::= {
{ NULL IDENTIFIED BY gnBasis } |
{ Trinomial IDENTIFIED BY tpBasis } |
{ Pentanomial IDENTIFIED BY ppBasis },
...
}
-- Trinomial basis representation of F2^m
-- Integer k for reduction polynomial xm + xk + 1
--
Trinomial ::= INTEGER
Pentanomial ::= SEQUENCE {
--
-- Pentanomial basis representation of F2^m
-- reduction polynomial integers k1, k2, k3
-- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
--
k1 INTEGER,
k2 INTEGER,
k3 INTEGER
}
CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(3) }
-- The object identifiers gnBasis, tpBasis and ppBasis name
-- three kinds of basis for characteristic-two finite fields
gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
FieldElement ::= OCTET STRING -- Finite field element
ECPoint ::= OCTET STRING -- Elliptic curve point
ECParameters ::= SEQUENCE { -- Elliptic curve parameters
version INTEGER { ecpVer1(1) } (ecpVer1),
Bassham, Johnson & Polk [Page 10]
INTERNET DRAFT October 21, 1999
fieldID FieldID {{FieldTypes}},
curve Curve,
base ECPoint, -- Base point G
order INTEGER, -- Order n of the base point
cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
...
}
Curve ::= SEQUENCE {
a FieldElement, -- Elliptic curve coefficient a
b FieldElement, -- Elliptic curve coefficient b
seed BIT STRING OPTIONAL
}
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier {{ECPKAlgorithms}},
subjectPublicKey BIT STRING
}
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm})
}
ECPKAlgorithms ALGORITHM ::= {
ecPublicKeyType,
...
}
ecPublicKeyType ALGORITHM ::= {
Parameters IDENTIFIED BY id-ecPublicKey
}
ALGORITHM ::= TYPE-IDENTIFIER
id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) }
id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
Bassham, Johnson & Polk [Page 11]
INTERNET DRAFT October 21, 1999
Parameters ::= CHOICE {
ecParameters ECParameters,
namedCurve CURVES.&id({CurveNames}),
implicitlyCA NULL
}
-- The following OIDS are defined in ANSI X9.62. ANSI, and
-- other standards bodies, may define other OIDs to represent
-- other elliptic curve parameters. Users are encouraged
-- to consult relevant standards and specifications to
-- determine which OIDs (if any) are appropriate for their
-- applications.
CurveNames CURVES ::= {
{ ID c2pnb163v1 } | -- J.4.1, example 1 --
{ ID c2pnb163v2 } | -- J.4.1, example 2 --
{ ID c2pnb163v3 } | -- J.4.1, example 3 --
{ ID c2pnb176w1 } | -- J.4.2, example 1 --
{ ID c2tnb191v1 } | -- J.4.3, example 1 --
{ ID c2tnb191v2 } | -- J.4.3, example 2 --
{ ID c2tnb191v3 } | -- J.4.3, example 3 --
{ ID c2onb191v4 } | -- J.4.3, example 4 --
{ ID c2onb191v5 } | -- J.4.3, example 5 --
{ ID c2pnb208w1 } | -- J.4.4, example 1 --
{ ID c2tnb239v1 } | -- J.4.5, example 1 --
{ ID c2tnb239v2 } | -- J.4.5, example 2 --
{ ID c2tnb239v3 } | -- J.4.5, example 3 --
{ ID c2onb239v4 } | -- J.4.5, example 4 --
{ ID c2onb239v5 } | -- J.4.5, example 5 --
{ ID c2pnb272w1 } | -- J.4.6, example 1 --
{ ID c2pnb304w1 } | -- J.4.7, example 1 --
{ ID c2tnb359v1 } | -- J.4.8, example 1 --
{ ID c2pnb368w1 } | -- J.4.9, example 1 --
{ ID c2tnb431r1 } | -- J.4.10, example 1 --
{ ID prime192v1 } | -- J.5.1, example 1 --
{ ID prime192v2 } | -- J.5.1, example 2 --
{ ID prime192v3 } | -- J.5.1, example 3 --
{ ID prime239v1 } | -- J.5.2, example 1 --
{ ID prime239v2 } | -- J.5.2, example 2 --
{ ID prime239v3 } | -- J.5.2, example 3 --
{ ID prime256v1 }, -- J.5.3, example 1 --
... -- others --
}
CURVES ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE
}
WITH SYNTAX { ID &id }
Bassham, Johnson & Polk [Page 12]
INTERNET DRAFT October 21, 1999
ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }
c-TwoCurve OBJECT IDENTIFIER ::= {
ellipticCurve characteristicTwo(0) }
primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }
c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 }
c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 }
c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 }
c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 }
c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 }
c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 }
c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 }
c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 }
c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 }
c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 }
c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 }
c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 }
c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 }
c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 }
c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 }
c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 }
c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 }
c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 }
c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 }
c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 }
prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 }
prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 }
prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 }
prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 }
prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 }
prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 }
prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 }
END
5 References
[X9.62] X9.62-1999, "Public Key Cryptography For The Financial
Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)".
[P1363] IEEE P1363, "Standard for Public-Key Cryptography", draft
standard, 1997.
Bassham, Johnson & Polk [Page 13]
INTERNET DRAFT October 21, 1999
[RFC 2459] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509
Public Key Infrastructure: Certificate and CRL Profile",
January, 1999.
6 Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information, consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
7 Security Considerations
This specification does not constrain the key sizes or identify
particular elliptic curves for use in the Internet PKI. However,
both the key size and the particular curve selected impact the 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 is a sound strategy. For additional information,
refer to X9.62 Appendix D.4, "Key Length Considerations" and Appendix
F.1, "Avoiding Cryptographically Weak Keys".
This specification is a profile of RFC 2459. The security
considerations section of that document applies to this specification
as well.
8 Author Addresses:
Larry Bassham
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
Bassham, Johnson & Polk [Page 14]
INTERNET DRAFT October 21, 1999
USA
lbassham@nist.gov
Don Johnson
Certicom
4253 Sleepy Lake Drive
Fairfax, VA 22033
USA
djohnson@certicom.com
Tim Polk
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
wpolk@nist.gov
Bassham, Johnson & Polk [Page 15]
