One document matched: draft-ietf-pkix-ecc-subpubkeyinfo-05.txt
Differences from draft-ietf-pkix-ecc-subpubkeyinfo-04.txt
PKIX WG Sean Turner, IECA
Internet Draft Daniel Brown, Certicom
Intended Status: Standard Track Kelvin Yiu, Microsoft
Updates: 3279 (once approved) Russ Housley, Vigil Security
Expires: October 16, 2008 Tim Polk, NIST
April 16, 2008
Elliptic Curve Cryptography Subject Public Key Information
draft-ietf-pkix-ecc-subpubkeyinfo-05.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 October 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies the syntax and semantics for the Subject
Public Key Information field in certificates that support Elliptic
Curve Cryptography. This document updates RFC 3279.
Turner, et al Expires October 16, 2008 [Page 1]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Table of Contents
1. Introduction...................................................2
1.1. Terminology...............................................3
2. Subject Public Key Information Fields..........................3
2.1. Elliptic Curve Cryptography Public Key
Algorithm Identifiers.....................................4
2.1.1. Unrestricted Identifiers and Parameters..............5
2.1.1.1. Named Curve.....................................6
2.1.1.2. Specified Curve.................................7
2.1.1.2.1. Specified Curve Version....................8
2.1.1.2.2. Field Identifiers..........................9
2.1.1.2.2.1. Prime-p..............................10
2.1.1.2.2.2. Characteristic-two...................10
2.1.1.2.3. Curve.....................................12
2.1.1.2.4. Base......................................12
2.1.1.2.5. Hash......................................13
2.1.2. Restricted Algorithm Identifiers and Parameters.....14
2.2. Subject Public Key.......................................15
3. KeyUsage Bits.................................................16
4. Security Considerations.......................................16
5. IANA Considerations...........................................16
6. References....................................................17
6.1. Normative References.....................................17
6.2. Informative References...................................17
Appendix A. ASN.1 Modules........................................18
Appendix A.1. 1988 ASN.1 Module...............................18
Appendix A.2. 2004 ASN.1 Module...............................26
1. Introduction
This document specifies the format of the subjectPublicKeyInfo field
in X.509 certificates [RFC3280] that use Elliptic Curve Cryptography
(ECC). It updates [RFC3279]. This document specifies the encoding
formats for public keys used with the following ECC algorithms:
Elliptic Curve Digital Signature Algorithm (ECDSA);
Elliptic Curve Diffie-Hellman (ECDH) family schemes; and,
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes.
Two methods for specifying the algorithms that can be used with the
subjectPublicKey are defined. One method does not restrict the
algorithms the key can be used with while the other method does
restrict the algorithms the key can be used with. To promote
Turner, et al Expires October 16, 2008 [Page 2]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
interoperability, this document indicates which is required to
implement.
Three methods for specifying the algorithm's parameters are also
defined. One allows for complete specification of the Elliptic Curve
(EC), one allows for the EC to be identified by an object identifier,
and one allows for the EC to be inherited from the issuer's
certificate. To promote interoperability, this document indicates
which options are required to implement.
Specification of all EC parameters is complicated with many options.
To promote interoperability, this document indicates which options
are required to implement.
1.1. Terminology
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 [RFC2119].
2. Subject Public Key Information Fields
In the X.509 certificate, the subjectPublicKeyInfo field has the
SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier {{PKAlgorithms}},
subjectPublicKey BIT STRING
}
The fields in SubjectPublicKeyInfo have the following meanings:
algorithm is the algorithm identifier and algorithm parameters
for the ECC public key. See paragraph 2.1.
subjectPublicKey is the ECC public key. See paragraph 2.2.
Turner, et al Expires October 16, 2008 [Page 3]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
The class ALGORITHM parameterizes the AlgorithmIdentifier type with
sets of legal values (this class is used in many places in this
document):
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
The type AlgorithmIdentifier is parameterized to allow legal sets of
values to be specified by constraining the type with an information
object set. There are two parameterized types for AlgorithmIdentifier
defined in this document: PKAlgorithms (see paragraph 2.1) and
HashFunctions (see paragraph 2.1.1.2.5).
AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
The fields in AlgorithmIdentifier have the following meaning:
algorithm identifies a cryptographic algorithm. The OBJECT
IDENTIFIER component identifies the algorithm. The contents of
the optional parameters field will vary according to the
algorithm identified.
parameters, which is optional, varies based on the algorithm
identified.
2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers
The algorithm field in the SubjectPublicKeyInfo structure indicates
the algorithms and any associated parameters for the ECC public key
(see paragraph 2.2). The algorithms are restricted to the
PKAlgorithms parameterized type, which uses the following ASN.1
structure:
PKAlgorithms ALGORITHM ::= {
pk-ec |
pk-ecDH |
pk-ecMQV,
... -- Extensible
}
Turner, et al Expires October 16, 2008 [Page 4]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
The algorithms defined are as follows:
pk-ec indicates that the algorithms that can be used with the
subject public key are not restricted (i.e., they are
unrestricted). The key is only restricted by the values
indicated in the key usage certificate extension. The pk-ec
CHOICE MUST be supported. See paragraph 2.1.1. This value is
also used when a key is used with ECDSA.
pk-ecDH and pk-ecMQV MAY be supported. See paragraph 2.1.2.
2.1.1. Unrestricted Identifiers and Parameters
The "unrestricted" algorithm is defined as follows:
pk-ec ALGORITHM ::= {
OID id-ecPublicKey PARMS ECParameters }
The algorithm identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
The parameters for id-ecPublicKey are as follows and they MUST always
be present:
ECParameters ::= CHOICE {
namedCurve CURVE.&id({NamedCurve}),
specifiedCurve SpecifiedCurve,
implicitCurve NULL
}
The fields in ECParameters have the following meanings:
namedCurve allows all the required values for a particular set of
elliptic curve domain parameters to be represented by an object
identifier. This choice MUST be supported. See paragraph
2.1.1.1.
specifiedCurve allows all of the required values to be explicitly
specified. This choice MAY be supported, and if it is,
implicitCurve MUST also be supported. See paragraph 2.1.1.2.
implicitCurve allows the elliptic curve parameters to be
inherited from the issuer's certificate. This choice MAY be
supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate
Turner, et al Expires October 16, 2008 [Page 5]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
MUST use the namedCurve option. That is, implicitCurve is only
supported if the superior doesn't use the namedCurve option.
2.1.1.1. Named Curve
The namedCurve field in ECParameters uses the class CURVE to
constrain the set of legal values from NamedCurve, which are object
identifiers:
CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX { ID &id }
The NamedCurve parameterized type is defined as follows:
NamedCurve CURVE ::= {
{ ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
{ ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
{ ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
{ ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
{ ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 },
... -- Extensible
}
The curve identifiers are the fifteen NIST recommended curves:
-- Note in ANSIX9.62 the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in RFC 3279 the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
sect163k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 1 }
sect163r2 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 15 }
secp224r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 33 }
sect233k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 26 }
Turner, et al Expires October 16, 2008 [Page 6]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
sect233r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 27 }
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
sect283k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 16 }
sect283r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 17 }
secp384r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 34 }
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
sect409r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 37 }
secp521r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 35 }
sect571k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 38 }
sect571r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 39 }
2.1.1.2. Specified Curve
The specifiedCurve field in ECParameters is of SpecifiedCurve type.
SpecifiedCurve uses the following ASN.1 structure:
SpecifiedCurve ::= SEQUENCE {
version SpecifiedCurveVersion
( ecpVer1 | ecpVer2 | ecpVer3, ... ),
fieldID FieldID {{FieldTypes}},
curve Curve, -- Curve E
base ECPoint, -- Base point P
order INTEGER, -- Order n of the base point
cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
hash HashAlgorithm OPTIONAL,
... -- Extensible
}
Turner, et al Expires October 16, 2008 [Page 7]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
The fields in SpecifiedCurve have the following meaning:
version specifies the version number of the elliptic curve
parameters. See paragraph 2.1.1.2.1.
fieldID identifies the finite field over which the elliptic
curve, specified in the curve field, is defined. See paragraph
2.1.1.2.2.
curve specifies the elliptic curve E. See paragraph 2.1.1.2.3.
base specifies the base point P on the elliptic curve E,
specified in the curve field. See paragraph 2.1.1.2.4.
order specifies the order n of the base point P, specified in
base.
cofactor is the order of the curve, specified in the curve field,
divided by the order, specified in the order field, of the base
point, specified in the base field (i.e., h = #E(Fq)/n).
Inclusion of the cofactor is optional; however, it is strongly
RECOMMENDED that that the cofactor be included in order to
facilitate interoperability between implementations.
hash is the hash algorithm used to generate the elliptic curve E,
specified in the curve field, and/or base point P, specified in
the base field, verifiably pseudorandomly. If the hash field is
omitted, then the hash algorithm shall be SHA1. See paragraph
2.1.1.2.5.
SpecifiedCurve is extensible. Extending SpecifiedCurve with new
fields or defining a new version number MUST be coordinated with the
ANSI X9.62 WG.
2.1.1.2.1. Specified Curve Version
The version field in SpecifiedCurve is of SpecifiedCurveVersion type.
SpecifiedCurveVersion uses the following ASN.1 structure:
SpecifiedCurveVersion ::= INTEGER {
ecpVer1(1),
ecpVer2(2),
ecpVer3(3)
}
SpecfifiedCurveVersion is ecdpVer1, ecdpVer2, or ecdpVer3. If
version is ecdpVer1, then the elliptic curve may or may not be
Turner, et al Expires October 16, 2008 [Page 8]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
verifiably pseudorandomly according to whether curve.seed (see
paragraph 2.1.1.2.3) is present, and the base point P (see paragraph
2.1.1.2.4) is not generated verifiably pseudorandomly. If version is
ecdpVer2, then the curve and the base point P shall be generated
verifiably pseudorandomly, and curve.seed shall be present. If
version is ecdpVer3, then the curve is not generated verifiably
pseudorandomly but the base point P shall be generated verifiably
pseudorandomly from curve.seed, which shall be present.
Implementations of this document MUST support ecpVer1.
2.1.1.2.2. Field Identifiers
The fieldID field in SpecifiedCurve is of FieldID type. 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.
The type FIELD-ID is defined by the following:
FIELD-ID ::= TYPE-IDENTIFIER
The FieldID parameterized type is defined as follows:
FieldID { FIELD-ID:IOSet } ::= SEQUENCE {
fieldType FIELD-ID.&id({IOSet}),
parameters FIELD-ID.&Type({IOSet}{@fieldType})
}
Field types are given in the following information object set:
FieldTypes FIELD-ID ::= {
{ Prime-p IDENTIFIED BY prime-field } |
{ Characteristic-two IDENTIFIED BY characteristic-two-field },
... -- Extensible
}
Two FieldTypes are defined herein: prime-p (see paragraph
2.1.1.2.2.1) and characteristic-two (see paragraph 2.1.1.2.2.2).
Implementations claiming conformance to this specification MUST
support the prime-p field type and MAY support the characteristic-two
field type. FieldTypes is extensible and other documents can specify
additional values for FieldTypes.
Turner, et al Expires October 16, 2008 [Page 9]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
2.1.1.2.2.1. Prime-p
A prime finite field is specified in FieldID.fieldType by the
following object identifier:
prime-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
The prime finite field parameters specified in FIELD-ID parameters
has the following ASN.1 structure:
Prime-p ::= INTEGER
Prime-p is an integer which is the size of the field.
2.1.1.2.2.2. Characteristic-two
A characteristic-two finite field is specified in FieldID.fieldType
by the following object identifier:
characteristic-two-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
The characteristic-two finite field parameters specified in
FieldID.parameters have the following ASN.1 structure:
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis CHARACTERISTIC-TWO.&id({BasisTypes}),
parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
}
The fields in Characteristic-two have the following meanings:
m is the size of the field.
basis is the type of basis used to express elements of the field.
parameters is the polynomial used to generate the field. The
parameters vary based on the basis.
The type CHARACTERISTIC-TWO is defined by the following:
CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
Turner, et al Expires October 16, 2008 [Page 10]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
The characteristic-two field basis types are given in the following
information object set:
BasisTypes CHARACTERISTIC-TWO ::= {
{ NULL IDENTIFIED BY gnBasis } |
{ Trinomial IDENTIFIED BY tpBasis } |
{ Pentanomial IDENTIFIED BY ppBasis },
... -- Extensible
}
Three basis types are defined herein: normal bases, trinomial bases,
and pentanomial bases. Implementation claiming conformance to this
document MUST support normal basis and MAY support trimonial and
pentanomial bases. BasisTypes is extensible and other documents can
specify additional values for BasisTypes.
Normal bases are specified in the basis field by the object
identifier:
gnBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 1 }
A normal base has NULL parameters.
A trinomial base specifies the degree of the middle term in the
defining trinomial. A trinomial base is identified in the basis field
by the object identifier:
tpBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 2 }
A trinomial base has the following parameters:
Trinomial ::= INTEGER
A pentanomial base specifies the degrees of the three middle terms in
the defining pentanomial. A pentanomial base is identified in the
basis field by the object identifier:
ppBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 3 }
Turner, et al Expires October 16, 2008 [Page 11]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
A pentanomial base has the following parameters:
Pentanomial ::= SEQUENCE {
k1 INTEGER, -- k1 > 0
k2 INTEGER, -- k2 > k1
k3 INTEGER -- k3 > k2
}
2.1.1.2.3. Curve
The curve field in SpecifiedCurve is of Curve type. Curve uses the
following ASN.1 structure:
Curve ::= SEQUENCE {
a FieldElement,
b FieldElement,
seed BIT STRING OPTIONAL
-- Shall be present if used in SpecifiedCurve
-- with version of ecdpVer2 or ecdpVer3
}
FieldElement ::= OCTET STRING
The fields in Curve have the following meanings:
a and b are the coefficients a and b, respectively, of the
elliptic curve E. Each coefficient, a and b, shall be represented
as a value of type FieldElement. Conversion routines for field
element to octet string are found in [SEC1].
seed is an optional parameter that is used to derive the
coefficients of a randomly generated elliptic curve. seed MUST
be present if SpecifiedECDomain is either ecdpVer2 or ecdpVer3.
2.1.1.2.4. Base
The base field in SpecifiedCurve is of ECPoint type. ECPoint uses
the following ASN.1 syntax:
ECPoint ::= OCTET STRING
The contents of ECPoint is the octet string representation of an
elliptic curve point. Conversion routines for point to octet string
are found in [SEC1]. Note that these octet strings may represent an
elliptic curve point in compressed or uncompressed form.
Implementations that support elliptic curve according to this
Turner, et al Expires October 16, 2008 [Page 12]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
document MUST support the uncompressed form and MAY support the
compressed form.
2.1.1.2.5. Hash
The hash field in SpecifiedCurve is of HashAlgorithm type.
HashAlgorithm uses the following ASN.1 syntax:
HashAlgorithm ::= AlgorithmIdentifier {{CurveHashFunctions}}
CurveHashAlgorithm is restricted to the HashFunctions parameterized
type, which uses the following ASN.1 structure:
CurveHashFunctions ALGORITHM ::= {
ow-sha1 |
ow-sha224 |
ow-sha256 |
ow-sha384 |
ow-sha512,
... -- Extensible
}
SHA1 [SHS] is defined as follows:
ow-sha1 ALGORITHM ::= {
OID id-sha1 PARMS NULL }
It has the following object identifier:
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
SHA224 [SHS] is defined as follows:
ow-sha224 ALGORITHM ::= {
OID id-sha224 PARMS NULL }
It has the following object identifier:
id-sha224 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
Turner, et al Expires October 16, 2008 [Page 13]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
SHA256 [SHS] is defined as follows:
ow-sha256 ALGORITHM ::= {
OID id-sha256 PARMS NULL }
It has the following object identifier:
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
SHA384 [SHS] is defined as follows:
ow-sha384 ALGORITHM ::= {
OID id-sha384 PARMS NULL }
It has the following object identifier:
id-sha384 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
SHA512 [SHS] is defined as follows:
ow-sha512 ALGORITHM ::= {
OID id-sha512 PARMS NULL }
It has the following object identifier:
id-sha512 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
An implementation of this document SHOULD accept values of the
parameterized type HashAlgorithm that have no parameters (also called
absent) and values that have NULL parameters. These values SHALL be
treated equally. (Of course, future extensions to the type parameter
HashFunctions might include information objects whose parameters
field is more meaningful.) An implementation of this document SHOULD
omit (leave absent) the parameters.
2.1.2. Restricted Algorithm Identifiers and Parameters
Algorithms used with elliptic curve cryptography fall in to different
categories: signature and key agreement algorithms. ECDSA uses the
pk-ec described in 2.1.1. Two sets of key agreement algorithms are
identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key
Turner, et al Expires October 16, 2008 [Page 14]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
key agreement scheme. All algorithms are identified by an OID and
have PARMS. The OID varies based on the algorithm but the PARMS are
always ECParameters and they MUST always be present (see paragraph
2.1.1).
The ECDH is defined as follows:
pk-ecDH ALGORITHM ::= {
OID id-ecDH PARMS ECParameters }
The algorithm identifier is:
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
The ECMQV is defined as follows:
pk-ecMQV ALGORITHM ::= {
OID id-ecMQV PARMS ECParameters }
The algorithm identifier is:
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
2.2. Subject Public Key
The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
Implementations of elliptic curve cryptography according to this
document MUST support the uncompressed form and MAY support the
compressed form of the ECC public key. As specified in [SEC1]:
The first byte of the key indicates whether the key is compressed
or uncompressed. The uncompressed form is indicated by 0x04 and
the compressed form is indicated by either 0x02 or 0x03 (see
2.3.3 in [SEC1]).
The elliptic curve public key (a value of type ECPoint which is
an OCTET STRING) is mapped to a subjectPublicKey (a value of type
BIT STRING) as follows: the most significant bit of the OCTET
STRING value becomes the most significant bit of the BIT STRING
value, and so on; the least significant bit of the OCTET STRING
becomes the least significant bit of the BIT STRING.
Turner, et al Expires October 16, 2008 [Page 15]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
3. KeyUsage Bits
If the keyUsage extension is present in a CA certificate that
indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of
the following values MAY be present:
digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.
If the CA certificate keyUsage extension asserts keyAgreement then it
MAY assert either encipherOnly or decipherOnly. However, this
specification RECOMMENDS that if keyCertSign or cRLSign is present,
keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
If the keyUsage extension is present in an EE certificate that
indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of
the following values MAY be present:
digitalSignature;
nonRepudiation; and
keyAgreement.
If the EE certificate keyUsage extension asserts keyAgreement then it
MAY assert either encipherOnly or decipherOnly.
If the keyUsage extension is present in a certificate that indicates
ecDH or ecMQV in subjectPublicKeyInfo, keyAgreement MUST be present
and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and
cRLSign MUST NOT be present. If this certificate keyUsage extension
asserts keyAgreement then it MAY assert either encipherOnly or
decipherOnly.
4. Security Considerations
The security considerations in [RFC3279] apply. No new security
considerations are introduced by this document.
5. IANA Considerations
None. Please remove this section prior to publication as an RFC.
Turner, et al Expires October 16, 2008 [Page 16]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certification Revocation List (CRL) Profile", RFC 3280,
April 2002.
[SHS] National Institute of Standards and Technology (NIST),
FIPS Publication 180-2: Secure Hash Standard, 2002.
[SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic
Curve Cryptography", Version 1.0, September 2000.
[X.208] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[X.680] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997.
[X.681] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One: Information Object
Spcification, 1997.
6.2. Informative References
[RFC3279] Polk, W., Housley, R. and L. Bassham, "Algorithm
Identifiers for the Internet X.509 Public Key
Infrastructure", RFC 3279, April 2002.
Turner, et al Expires October 16, 2008 [Page 17]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Appendix A. ASN.1 Modules
Appendix A.1 provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[X.208].
Appendix A.2 provides an informative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[X.680,X.681]. This appendix contains the same information as
Appendix A.1 in a more recent (and precise) ASN.1 notation, however
Appendix A.1 takes precedence in case of conflict.
These modules includes more than the ASN.1 updates described in the
text of this document. It also includes additional ASN.1 from RFC3279
because we needed to update the entire ASN.1 module.
Appendix A.1. 1988 ASN.1 Module
PKIXAlgs-2008 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) }
;
--
-- Public Key (pk) Algorithms
--
-- RSA PK Algorithm, Parameters, and Keys
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
Turner, et al Expires October 16, 2008 [Page 18]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
-- DSA PK Algorithm and Parameters
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
DSAPublicKey ::= INTEGER -- public key, y
DSS-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER
}
-- Diffie-Hellman PK Algorithm, Keys, and Parameters
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
-- KEA PK Algorithm and Parameters
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 1 22 }
KEA-Parms-Id ::= OCTET STRING
-- Sec 2.1.1 Unrestricted Algorithms and Parameters (including ECDSA)
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
Turner, et al Expires October 16, 2008 [Page 19]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- Sec 2.1.2 Restricted Algorithms and Parameters
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- Sec 2.1.2 Restricted Algorithms and Parameters
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
-- Parameters for both Restricted and Unrestricted
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER,
specifiedCurve SpecifiedCurve,
implicitCurve NULL
}
-- Sec 2.1.1.1 Named Curves
-- Note in ANSIX9.62 the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in RFC 3279 the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
sect163k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 1 }
sect163r2 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 15 }
secp224r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 33 }
sect233k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 26 }
sect233r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 27 }
Turner, et al Expires October 16, 2008 [Page 20]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
sect283k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 16 }
sect283r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 17 }
secp384r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 34 }
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
sect409r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 37 }
secp521r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 35 }
sect571k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 38 }
sect571r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 39 }
-- Sec 2.1.1.2 Specified Curve
SpecifiedCurve ::= SEQUENCE {
version SpecifiedCurveVersion,
fieldID FieldID,
curve Curve, -- Curve E
base ECPoint, -- Base point P
order INTEGER, -- Order n of the base point
cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
hash HashAlgorithm OPTIONAL
}
SpecifiedCurveVersion ::= INTEGER {
ecpVer1(1),
ecpVer2(2),
ecpVer3(3)
}
Turner, et al Expires October 16, 2008 [Page 21]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
FieldID ::= SEQUENCE {
fieldType OBJECT IDENTIFIER,
parameters ANY DEFINED BY fieldType
}
-- where fieldType is prime-field, the parameters are of type Prime-p
prime-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
Prime-p ::= INTEGER
-- where fieldType is characteristic-two-field, the parameters are
-- of type Characteristic-two
characteristic-two-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis OBJECT IDENTIFIER,
parameters ANY DEFINED BY basis
}
-- The object identifiers gnBasis, tpBasis and ppBasis name
-- three kinds of basis for characteristic-two finite fields
-- gnbasis is identified by OID gnBasis and indicates
-- parameters are NULL
gnBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 1 }
-- trinomial basis is identified by OID tpBasis and indicates
-- parameters of type Pentanomial
tpBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 2 }
Trinomial ::= INTEGER
-- for pentanomial basis is identified by OID ppBasis and indicates
-- parameters of type Pentanomial
Turner, et al Expires October 16, 2008 [Page 22]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
ppBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 3 }
-- Pentanomial basis representation of F2^m
-- reduction polynomial integers k1, k2, k3
-- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
Pentanomial ::= SEQUENCE {
k1 INTEGER, -- k1 > 0
k2 INTEGER, -- k2 > k1
k3 INTEGER -- k3 > k2
}
Curve ::= SEQUENCE {
a FieldElement, -- Elliptic curve coefficient a
b FieldElement, -- Elliptic curve coefficient b
seed BIT STRING OPTIONAL
-- Shall be present if used in SpecifiedCurve
-- with version of ecdpVer2 or ecdpVer3
}
FieldElement ::= OCTET STRING
ECPoint ::= OCTET STRING
HashAlgorithm ::= AlgorithmIdentifier
--
-- Signature Algorithms (sa)
--
-- RSA with MD-2
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }
-- RSA with MD-5
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
-- RSA with SHA-1
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
Turner, et al Expires October 16, 2008 [Page 23]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- DSA with SHA-1
dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }
-- ECDSA with SHA-1
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
--
-- Signature Values
--
-- DSA
DSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- ECDSA
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
--
-- One-way (ow) Hash Algorithms
--
-- MD-2
id-md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }
-- MD-5
id-md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }
-- SHA-1
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
Turner, et al Expires October 16, 2008 [Page 24]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- SHA-224
id-sha224 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
-- SHA-256
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
-- SHA-384
id-sha384 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
-- SHA-512
id-sha512 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
END
Turner, et al Expires October 16, 2008 [Page 25]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Appendix A.2. 2004 ASN.1 Module
PKIXAlgs-2008 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
-- IMPORTS NONE
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
--
-- Public Key (pk) Algorithms
--
PKAlgorithms ALGORITHM ::= {
pk-rsa |
pk-dsa |
pk-dh |
pk-kea |
pk-ec |
pk-ecDH |
pk-ecMQV,
... -- Extensible
}
-- RSA PK Algorithm, Parameters, and Keys
pk-rsa ALGORITHM ::= {
OID rsaEncryption PARMS NULL }
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
Turner, et al Expires October 16, 2008 [Page 26]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
-- DSA PK Algorithm, Parameters, and Keys
pk-dsa ALGORITHM ::= {
OID id-dsa PARMS DSS-Parms }
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
DSS-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER
}
DSAPublicKey ::= INTEGER -- public key, y
-- Diffie-Hellman PK Algorithm, Parameters, and Keys
pk-dh ALGORITHM ::= {
OID dhpublicnumber PARMS DomainParameters }
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
-- KEA PK Algorithm and Parameters
pk-kea ALGORITHM ::= {
OID id-keyExchangeAlgorithm PARMS KEA-Parms-Id }
Turner, et al Expires October 16, 2008 [Page 27]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 1 22 }
KEA-Parms-Id ::= OCTET STRING
-- Sec 2.1.1 Unrestricted Algorithms and Parameters (including ECDSA)
pk-ec ALGORITHM ::= {
OID id-ecPublicKey PARMS ECParameters }
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
-- Sec 2.1.2 Restricted Algorithms and Parameters
pk-ecDH ALGORITHM ::= {
OID id-ecDH PARMS ECParameters }
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- Sec 2.1.2 Restricted Algorithms and Parameters
pk-ecMQV ALGORITHM ::= {
OID id-ecMQV PARMS ECParameters }
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
-- Parameters for both Restricted and Unrestricted
ECParameters ::= CHOICE {
namedCurve CURVE.&id({NamedCurve}),
specifiedCurve SpecifiedCurve,
implicitCurve NULL
}
-- Sec 2.1.1.1 Named Curve
CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX { ID &id }
Turner, et al Expires October 16, 2008 [Page 28]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
NamedCurve CURVE ::= {
{ ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
{ ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
{ ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
{ ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
{ ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 },
... -- Extensible
}
-- Note in ANSIX9.62 the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in RFC 3279 the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
sect163k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 1 }
sect163r2 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 15 }
secp224r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 33 }
sect233k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 26 }
sect233r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 27 }
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
sect283k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 16 }
sect283r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 17 }
secp384r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 34 }
Turner, et al Expires October 16, 2008 [Page 29]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
sect409r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 37 }
secp521r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 35 }
sect571k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 38 }
sect571r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 39 }
-- Sec 2.1.1.2 Specified Curve
SpecifiedCurve ::= SEQUENCE {
version SpecifiedCurveVersion
( ecpVer1 | ecpVer2 | ecpVer3, ... ),
fieldID FieldID {{FieldTypes}},
curve Curve, -- Curve E
base ECPoint, -- Base point P
order INTEGER, -- Order n of the base point
cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
hash HashAlgorithm OPTIONAL,
... -- Extensible
}
SpecifiedCurveVersion ::= INTEGER {
ecpVer1(1),
ecpVer2(2),
ecpVer3(3)
}
FIELD-ID ::= TYPE-IDENTIFIER
FieldID { FIELD-ID:IOSet } ::= SEQUENCE {
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 },
... -- Extensible
}
Turner, et al Expires October 16, 2008 [Page 30]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- where fieldType is prime-field, the parameters are of type Prime-p
prime-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
Prime-p ::= INTEGER
-- where fieldType is characteristic-two-field, the parameters are
-- of type Characteristic-two
characteristic-two-field OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis CHARACTERISTIC-TWO.&id({BasisTypes}),
parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
}
CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
-- The object identifiers gnBasis, tpBasis and ppBasis name
-- three kinds of basis for characteristic-two finite fields
BasisTypes CHARACTERISTIC-TWO ::= {
{ NULL IDENTIFIED BY gnBasis } |
{ Trinomial IDENTIFIED BY tpBasis } |
{ Pentanomial IDENTIFIED BY ppBasis },
... -- Extensible
}
-- gnbasis is identified by OID gnBasis and indicates
-- parameters are NULL
gnBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 1 }
-- trinomial basis is identified by OID tpBasis and indicates
-- parameters of type Pentanomial
tpBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 2 }
Turner, et al Expires October 16, 2008 [Page 31]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Trinomial ::= INTEGER
-- for pentanomial basis is identified by OID ppBasis and indicates
-- parameters of type Pentanomial
ppBasis OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
characteristic-two-basis(2) 3 }
-- Pentanomial basis representation of F2^m
-- reduction polynomial integers k1, k2, k3
-- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
Pentanomial ::= SEQUENCE {
k1 INTEGER, -- k1 > 0
k2 INTEGER, -- k2 > k1
k3 INTEGER -- k3 > k2
}
Curve ::= SEQUENCE {
a FieldElement,
b FieldElement,
seed BIT STRING OPTIONAL
-- Shall be present if used in SpecifiedCurve
-- with version of ecdpVer2 or ecdpVer3
}
FieldElement ::= OCTET STRING
ECPoint ::= OCTET STRING
HashAlgorithm ::= AlgorithmIdentifier {{CurveHashFunctions}}
CurveHashFunctions ALGORITHM ::= {
ow-sha1 |
ow-sha224 |
ow-sha256 |
ow-sha384 |
ow-sha512,
... -- Extensible
}
Turner, et al Expires October 16, 2008 [Page 32]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
--
-- Signature Algorithms (sa)
--
SignatureAlgorithms ALGORITHM ::= {
sa-rsaWithMD2 |
sa-rsaWithMD5 |
sa-rsaWithSHA1 |
sa-dsawithSHA1 |
sa-ecdsaWithSHA1,
... -- Extensible
}
-- RSA with MD-2
sa-rsaWithMD2 ALGORITHM ::= {
OID md2WithRSAEncryption PARMS NULL }
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }
-- RSA with MD-5
sa-rsaWithMD5 ALGORITHM ::= {
OID md5WithRSAEncryption PARMS NULL }
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
-- RSA with SHA-1
sa-rsaWithSHA1 ALGORITHM ::= {
OID sha1WithRSAEncryption PARMS NULL }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
-- DSA with SHA-1
sa-dsaWithSHA1 ALGORITHM ::= {
OID dsa-with-sha1 PARMS NULL }
dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }
Turner, et al Expires October 16, 2008 [Page 33]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- ECDSA with SHA-1
sa-ecdsaWithSHA1 ALGORITHM ::= {
OID ecdsa-with-sha1 PARMS NULL }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
--
-- Signature Values
--
-- DSA
DSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- ECDSA
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
--
-- One-way (ow) Hash Algorithms
--
HashAlgorithms ALGORITHM ::= {
ow-md2 |
ow-md5 |
ow-sha1 |
ow-sha224 |
ow-sha256 |
ow-sha384 |
ow-sha512,
... -- Extensible
}
-- MD-2
ow-md2 ALGORITHM ::= {
OID id-md2 PARMS NULL }
Turner, et al Expires October 16, 2008 [Page 34]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
id-md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }
-- MD-5
ow-md5 ALGORITHM ::= {
OID id-md5 PARMS NULL }
id-md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }
-- SHA-1
ow-sha1 ALGORITHM ::= {
OID id-sha1 PARMS NULL }
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
-- SHA-224
ow-sha224 ALGORITHM ::= {
OID id-sha224 PARMS NULL }
id-sha224 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
-- SHA-256
ow-sha256 ALGORITHM ::= {
OID id-sha256 PARMS NULL }
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
-- SHA-384
ow-sha384 ALGORITHM ::= {
OID id-sha384 PARMS NULL }
id-sha384 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
Turner, et al Expires October 16, 2008 [Page 35]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
-- SHA-512
ow-sha512 ALGORITHM ::= {
OID id-sha512 PARMS NULL }
id-sha512 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
END
Turner, et al Expires October 16, 2008 [Page 36]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Authors' Addresses
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: turners@ieca.com
Kelvin Yiu
Microsoft
One Microsoft Way
Redmond, WA 98052-6399
USA
Email: kelviny@microsoft.com
Daniel R. L. Brown
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
CANADA
EMail: dbrown@certicom.com
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Tim Polk
NIST
Building 820, Room 426
Gaithersburg, MD 20899
USA
EMail: wpolk@nist.gov
Turner, et al Expires October 16, 2008 [Page 37]
Internet-Draft ECC SubjectPublicKeyInfo Format April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 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, 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Turner, et al Expires October 16, 2008 [Page 38]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:22 |