One document matched: draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Differences from draft-ietf-pkix-ecc-subpubkeyinfo-07.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: March 18, 2009 Tim Polk, NIST
September 18, 2008
Elliptic Curve Cryptography Subject Public Key Information
draft-ietf-pkix-ecc-subpubkeyinfo-08.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 March 18, 2009.
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 Sections 2.3.5, 3, and 5
of RFC 3279.
Turner, et al Expires March 18, 2009 [Page 1]
Internet-Draft ECC SubjectPublicKeyInfo Format September 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.2. Restricted Algorithm Identifiers and Parameters......7
2.2. Subject Public Key........................................8
3. Key Usage Bits.................................................9
4. Security Considerations.......................................10
5. ASN.1 Considerations..........................................12
6. IANA Considerations...........................................12
7. Acknowledgements..............................................13
8. References....................................................13
8.1. Normative References.....................................13
8.2. Informative References...................................14
Appendix A. ASN.1 Modules........................................15
A.1. 1988 ASN.1 Module........................................15
A.2. 2004 ASN.1 Module........................................22
1. Introduction
This document specifies the format of the subjectPublicKeyInfo field
in X.509 certificates [PKI] that use Elliptic Curve Cryptography
(ECC). It updates [PKI-ALG]. This document specifies the encoding
formats for public keys used with the following ECC algorithms:
o Elliptic Curve Digital Signature Algorithm (ECDSA);
o Elliptic Curve Diffie-Hellman (ECDH) family schemes; and,
o 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
interoperability, this document indicates which is required to
implement.
Two methods for specifying the algorithm's parameters are also
defined. 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.
Turner, et al Expires March 18, 2009 [Page 2]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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 {{ PKIXAlgs-PublicKeys }},
subjectPublicKey BIT STRING
}
The fields in SubjectPublicKeyInfo have the following meanings:
o algorithm is the algorithm identifier and algorithm parameters
for the ECC public key. See Section 2.1.
o subjectPublicKey is the ECC public key. See Section 2.2.
The class PUBLIC-KEY parameterizes the AlgorithmIdentifier type with
sets of legal values, which is defined in [PKI-ASN]:
PUBLIC-KEY ::= CLASS {
&id OBJECT IDENTIFIER,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT required,
&KeyValue,
&PrivateKey OPTIONAL
}
WITH SYNTAX {
IDENTIFIER &id
KEY &KeyValue
[PARAMS TYPE [&Params] ARE ¶mPresence]
[PRIVATE KEY &PrivateKey]
}
Turner, et al Expires March 18, 2009 [Page 3]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
ParamOptions ::= ENUMERATED {
required, -- Parameters MUST be encoded in structure
preferedPresent, -- Parameters SHOULD be encoded in structure
preferedAbsent, -- Parameters SHOULD NOT be encoded in structure
absent, -- Parameters MUST NOT be encoded in structure
notPresent,
inheritable -- Parameters are inherited if not present
}
The type AlgorithmIdentifier is parameterized to allow legal sets of
values to be specified by constraining the type with an information
object set.
When defining a PUBLIC-KEY type:
o &id is the object identifier assigned to the public-key type.
o &Params, which is optional, is the parameters for the public-
key type.
o ¶mPresence parameter presence requirement
o &KeyValue contains the type for the public key value
o &PrivateKey is the associated private key format.
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 Section 2.2). The algorithms are restricted to the
PKIXAlgs-PublicKeys parameterized type, which uses the following
ASN.1 structure:
PKIXAlgs-PublicKeys PUBLIC-KEY ::= {
pk-ec |
pk-ecDH |
pk-ecMQV,
... -- Extensible
}
The algorithms defined are as follows:
o 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
Turner, et al Expires March 18, 2009 [Page 4]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
CHOICE MUST be supported. See Section 2.1.1. This value is
also used when a key is used with ECDSA.
o pk-ecDH and pk-ecMQV MAY be supported. See Section 2.1.2.
2.1.1. Unrestricted Identifiers and Parameters
The "unrestricted" algorithm is defined as follows:
pk-ec PUBLIC-KEY ::= {
IDENTIFIER id-ecPublicKey
KEY ECPoint
PARAMS TYPE ECParameters ARE required
}
The algorithm identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
The public key syntax is described in Section 2.2.
The parameters for id-ecPublicKey are as follows and they MUST always
be present:
ECParameters ::= CHOICE {
namedCurve CURVE.&id({NamedCurve}),
implicitCurve NULL
-- specifiedCurve SpecifiedCurve
-- specifiedCurve MUST NOT be used in PKIX
-- Details for specifiedCurve can be found in [X9.62]
-- Any future additions to this CHOICE should be coordinated
-- with ASNI X.9.
}
The fields in ECParameters have the following meanings:
o 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 Section
2.1.1.1.
o implicitCurve allows the elliptic curve parameters to be
inherited. This choice MAY be supported, but if subordinate
certificates use the same namedCurve as their superior, then
the subordinate certificate MUST use the namedCurve option.
Turner, et al Expires March 18, 2009 [Page 5]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
That is, implicitCurve is only supported if the superior
doesn't use the namedCurve option.
o specifedCuve, which is defined in [X9.62], allows all of the
curve parameters to be explicitly specified. This choice MUST
NOT be used. See the ASN.1 Considerations section.
The addition of any new choices in ECParameters ought to be
coordinated with ANSI X9.
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
[FIPS186-3]:
-- Note in [X9.62] the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp384r1 as P-384, and secp521r1 as P-521.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
Turner, et al Expires March 18, 2009 [Page 6]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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 }
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.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
Turner, et al Expires March 18, 2009 [Page 7]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
pk-ec described in 2.1.1. Two sets of key agreement algorithms are
identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key
agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
key agreement scheme. All algorithms are identified by an object
identifier and have parameters. The object identifier varies based
on the algorithm but the parameters are always ECParameters and they
MUST always be present (see Section 2.1.1).
The ECDH is defined as follows:
pk-ecDH PUBLIC-KEY ::= {
IDENTIFIER id-ecDH
KEY ECPoint
PARAMS TYPE ECParameters ARE required
}
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 PUBLIC-KEY ::= {
IDENTIFIER id-ecMQV
KEY ECPoint
PARAMS TYPE ECParameters ARE required
}
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.
ECC public keys have the following syntax:
ECPoint ::= OCTET STRING
Turner, et al Expires March 18, 2009 [Page 8]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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]:
o 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.
Conversion routines are found in Sections 2.3.1 and 2.3.2 of
[SEC1].
o The first octet of the OCTET STRING 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]).
3. Key Usage 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.
Turner, et al Expires March 18, 2009 [Page 9]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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 [PKI-ALG] apply.
When implementing ECC in X.509 Certificates, there are three
algorithm related choices that need to be made:
1) What is the public key size?
2) What is the hash algorithm [FIPS180-3]?
3) What is the curve?
Consideration must be given to the strength of the security provided
by each of these choices. Security is measured in bits, where a
strong symmetric cipher with a key of X bits is said to provide X
bits of security. It is recommended that the bits of security
provided by each choice are roughly equivalent. The following table
provides comparable minimum bits of security [SP800-57] for the ECDSA
key sizes and message digest algorithms. It also lists curves (see
Section 2.1.1.1) for the key sizes.
Turner, et al Expires March 18, 2009 [Page 10]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 160-223 | SHA1 | sect163k1
| | SHA224 | secp163r2
| | SHA256 | secp192r1
| | SHA384 |
| | SHA512 |
---------+----------+------------+-----------
112 | 224-255 | SHA224 | secp224r1
| | SHA256 | sect233k1
| | SHA384 | sect233r1
| | SHA512 |
---------+----------+------------+-----------
128 | 256-383 | SHA256 | secp256r1
| | SHA384 | sect283k1
| | SHA512 | sect283r1
---------+----------+------------+-----------
192 | 384-511 | SHA384 | secp384r1
| | SHA512 | sect409k1
| | | sect409r1
---------+----------+------------+-----------
256 | 512+ | SHA512 | secp521r1
| | | sect571k1
| | | sect571r1
---------+----------+------------+-----------
To promote interoperability, the following choices are RECOMMENDED:
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 192 | SHA256 | secp192r1
---------+----------+------------+-----------
112 | 224 | SHA256 | secp224r1
---------+----------+------------+-----------
128 | 256 | SHA256 | secp256r1
---------+----------+------------+-----------
192 | 384 | SHA384 | secp384r1
---------+----------+------------+-----------
256 | 512 | SHA512 | secp521r1
---------+----------+------------+-----------
Using a larger hash value and then truncating it, consumes more
processing power than is necessary. This is more important on
Turner, et al Expires March 18, 2009 [Page 11]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
constrained devices. Since the signer does not know the environment
that the recipient will use to validate the signature, it is better
to use a hash function that provides the desired have value output
size, and no more.
There are security risks with using keys not associated with well
known and widely reviewed curves. For example, the curve may not
satisfy the MOV condition or the curve may be vulnerable to the
Anomalous attack [X9.62]. Additionally, either a) all of the
arithmetic properties of a candidate ECC public key must be validated
to ensure that it has the unique correct representation in the
correct (additive) subgroup (and therefore is also in the correct EC
group) specified by the associated ECC domain parameters or b) some
of the of the arithmetic properties of a candidate ECC public key
must be validated to ensure that it is in the correct group (but not
necessarily the correct subgroup) specified by the associated ECC
domain parameters [SP800-56A].
5. ASN.1 Considerations
[X9.62] defines additional options for ECParameters and ECDSA-Sig-
Value. If an implementation needs to use these options, then use
the [X9.62] ASN.1 module. This RFC contains a conformant subset of
the ASN.1 module defined in [X9.62].
If an implementations generates a PER [X.691] encoding using the
ASN.1 module found in this specification it might not achieve the
same encoded output as one that uses the [X9.62] module. PER is not
required by either the PKIX or S/MIME environments. If an
implementation environment requires PER, then implementation concerns
are less likely with the use of the [X9.62] module.
6. IANA Considerations
This document makes extensive use of object identifiers to register
public key types, elliptic curves, field types, and algorithms. Most
are registered in the ANSI X9.62 arc with exception of the hash
algorithms, which are in NIST's arc, and many of the curves, which
are in the Certicom Inc. arc (these curves have adopted by ANSI and
NIST). Additionally, object identifiers are used to identify the
ASN.1 modules found in Appendix A. These are defined in an arc
delegated by IANA to the PKIX Working Group. No further action by
IANA is necessary for this document or any anticipated updates.
Turner, et al Expires March 18, 2009 [Page 12]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
7. Acknowledgements
The authors wish to thank Alfred Hoenes, Johannes Merkle, and Jim
Schaad for their valued input.
8. References
8.1. Normative References
[FIPS180-3] National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard, June 2007.
[FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard, March
2006.
[PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for PKIX",
draft-ietf-pkix-new-asn1, work-in-progress.
[PKI-ADALG] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
draft-ietf-pkix-sha2-dsa-ecdsa, work-in-progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "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.
[SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic
Curve Cryptography", Version 1.0, September 2000.
[X9.62] American National Standards Institute (ANSI), ANS X9.62-
2005: The Elliptic Curve Digital Signature Algorithm
(ECDSA), 2005.
[X.208] ITU-T Recommendation X.208 (1988) | ISO/IEC 8824-1:1988.
Specification of Abstract Syntax Notation One (ASN.1).
Turner, et al Expires March 18, 2009 [Page 13]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
Information Technology - Abstract Syntax Notation One.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
Information Technology - Abstract Syntax Notation One:
Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
Information Technology - Abstract Syntax Notation One:
Constraint Specification.
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.
Information Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications.
8.2. Informative References
[PKI-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithm
Identifiers for the Internet X.509 Public Key
Infrastructure", RFC 3279, April 2002.
[SP800-56A] National Institute of Standards and Technology (NIST),
Special Publication 800-56A: Recommendation Pair-Wise Key
Establishment Schemes Using Discrete Logarithm
Cryptography (Revised), March 2007.
[SP800-57] National Institute of Standards and Technology (NIST),
Special Publication 800-57: Recommendation for Key
Management, August 2005.
[X.691] ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002.
Information Technology - ASN.1 Encoding Rules:
Specification of Packed Encoding Rules.
Turner, et al Expires March 18, 2009 [Page 14]
Internet-Draft ECC SubjectPublicKeyInfo Format September 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], [X.682], and [X.683]. 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 include more than the ASN.1 updates described in the
text of this document. They also include additional ASN.1 from [PKI-
ALG] because this document updates the entire ASN.1 module.
Additionally, it includes ASN.1 for DSA with SHA-224 and SHA-256
[PKI-ADALG].
A.1. 1988 ASN.1 Module
PKIXAlgs-1988 { 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
-- From [RSAOAEP]
id-sha224, id-sha256, id-sha384, id-sha512
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
;
Turner, et al Expires March 18, 2009 [Page 15]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
--
-- 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 }
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
}
Turner, et al Expires March 18, 2009 [Page 16]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- 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 Algorithm IDs, Parameters, and Keys
-- (ECDSA keys use id-ecPublicKey)
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
ECPoint ::= OCTET STRING
-- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- ECPoint ::= OCTET STRING
-- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
-- ECPoint ::= OCTET STRING
-- Parameters for both Restricted and Unrestricted
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER,
implicitCurve NULL
-- specifiedCurve SpecifiedCurve
-- specifiedCurve MUST NOT be used in PKIX
-- Details for specifiedCurve can be found in [X9.62]
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X.9.
}
Turner, et al Expires March 18, 2009 [Page 17]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- Sec 2.1.1.1 Named Curves
-- Note in [X9.62] the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp384r1 as P-384, and secp521r1 as P-521.
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 }
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
Turner, et al Expires March 18, 2009 [Page 18]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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 }
--
-- Signature Algorithms (sa)
--
-- RSA with MD-2
-- Parameters are NULL
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }
-- RSA with MD-5
-- Parameters are NULL
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
-- RSA with SHA-1
-- Parameters are NULL
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
-- DSA with SHA-1
-- Parameters are ABSENT
dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }
-- DSA with SHA-224
-- Parameters are ABSENT
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 }
Turner, et al Expires March 18, 2009 [Page 19]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- DSA with SHA-256
-- Parameters are ABSENT
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 }
-- ECDSA with SHA-1
-- Parameters are ABSENT
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
-- ECDSA with SHA-224
-- Parameters are ABSENT
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 SHA-256
-- Parameters are ABSENT
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 SHA-384
-- Parameters are ABSENT
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 SHA-512
-- Parameters are ABSENT
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4 }
Turner, et al Expires March 18, 2009 [Page 20]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
--
-- 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
-- Parameters are NULL
id-md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }
-- MD-5
-- Parameters are NULL
id-md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }
-- SHA-1
-- Parameters are preferred ABSENT
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
-- SHA-224
-- Parameters are preferred ABSENT
-- id-sha224
Turner, et al Expires March 18, 2009 [Page 21]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- SHA-256
-- Parameters are preferred ABSENT
-- id-sha256
-- SHA-384
-- Parameters are preferred ABSENT
-- id-sha384
-- SHA-512
-- Parameters are preferred ABSENT
-- id-sha512
END
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
-- FROM [PKI-ASN]
PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM
FROM AlgorithmInformation
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithInformation(TBD) }
-- From [PKI-ASN]
mda-sha224, mda-sha256, mda-sha384, mda-sha512
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) TBD }
;
Turner, et al Expires March 18, 2009 [Page 22]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
--
-- Public Key (pk-) Algorithms
--
PKIXAlgs-PublicKeys PUBLIC-KEY ::= {
pk-rsa |
pk-dsa |
pk-dh |
pk-kea |
pk-ec |
pk-ecDH |
pk-ecMQV,
... -- Extensible
}
-- RSA PK Algorithm, Parameters, and Keys
pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE absent
-- Private key format not in this document --
}
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
-- DSA PK Algorithm, Parameters, and Keys
pk-dsa PUBLIC-KEY ::= {
IDENTIFIER id-dsa
KEY DSAPublicKey
PARAMS TYPE DSS-Parms ARE inheritable
-- Private key format not in this document --
}
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
Turner, et al Expires March 18, 2009 [Page 23]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
DSS-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER
}
DSAPublicKey ::= INTEGER -- public key, y
-- Diffie-Hellman PK Algorithm, Parameters, and Keys
pk-dh PUBLIC-KEY ::= {
IDENTIFIER dhpublicnumber
KEY DHPublicKey
PARAMS TYPE DomainParameters ARE inheritable
-- Private key format not in this document --
}
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 PUBLIC-KEY ::= {
IDENTIFIER id-keyExchangeAlgorithm
-- key is not encoded --
PARAMS TYPE KEA-Parms-Id ARE required
-- Private key format not in this document --
}
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {
2 16 840 1 101 2 1 1 22 }
Turner, et al Expires March 18, 2009 [Page 24]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
KEA-Parms-Id ::= OCTET STRING
-- Sec 2.1.1 Unrestricted Algorithms IDs, Parameters, and Keys
-- (ECDSA uses pk-ec)
pk-ec PUBLIC-KEY ::= {
IDENTIFIER id-ecPublicKey
KEY ECPoint
PARAMS TYPE ECParameters ARE required
-- Private key format not in this document --
}
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
ECPoint ::= OCTET STRING
-- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys
pk-ecDH PUBLIC-KEY ::= {
IDENTIFIER id-ecDH
KEY ECPoint
PARAMS TYPE ECParameters ARE required
-- Private key format not in this document --
}
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys
pk-ecMQV PUBLIC-KEY ::= {
IDENTIFIER id-ecMQV
KEY ECPoint
PARAMS TYPE ECParameters ARE required
-- Private key format not in this document --
}
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
Turner, et al Expires March 18, 2009 [Page 25]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- Parameters for both Restricted and Unrestricted
ECParameters ::= CHOICE {
namedCurve CURVE.&id({NamedCurve}),
implicitCurve NULL,
-- specifiedCurve SpecifiedCurve
-- specifiedCurve MUST NOT be used in PKIX
-- Details for specifiedCurve can be found in [X9.62]
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X.9.
}
-- Sec 2.1.1.1 Named Curve
CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX { ID &id }
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 [X9.62] the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as
-- prime192v1 and the secp256v1 curve was referred to as secp256r1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp384r1 as P-384, and secp521r1 as P-521.
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 }
Turner, et al Expires March 18, 2009 [Page 26]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
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 }
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 }
Turner, et al Expires March 18, 2009 [Page 27]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
--
-- Signature Algorithms (sa-)
--
PKIXAlgs-Signature SIGNATURE-ALGORITHM ::= {
sa-rsaWithMD2 |
sa-rsaWithMD5 |
sa-rsaWithSHA1 |
sa-dsawithSHA1 |
sa-dsawithSHA224 |
sa-dsawithSHA256 |
sa-ecdsaWithSHA1 |
sa-ecdsaWithSHA224 |
sa-ecdsaWithSHA256 |
sa-ecdsaWithSHA384 |
sa-ecdsaWithSHA512,
... -- Extensible
}
-- RSA with MD-2
sa-rsaWithMD2 SIGNATURE-ALGORITHM ::= {
IDENTIFIER md2WithRSAEncryption
PARAMS TYPE NULL ARE present
HASHES { mda-md2 }
PUBLIC KEYS { pk-rsa }
}
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }
-- RSA with MD-5
sa-rsaWithMD5 SIGNATURE-ALGORITHM ::= {
IDENTIFIER md5WithRSAEncryption
PARAMS TYPE NULL ARE present
HASHES { mda-md5 }
PUBLIC KEYS { pk-rsa }
}
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
Turner, et al Expires March 18, 2009 [Page 28]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- RSA with SHA-1
sa-rsaWithSHA1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER sha1WithRSAEncryption
PARAMS TYPE NULL ARE present
HASHES { mda-sha1 }
PUBLIC KEYS { pk-rsa }
}
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
-- DSA with SHA-1
sa-dsaWithSHA1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER dsa-with-sha1
VALUE DSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha1 }
PUBLIC KEYS { pk-dsa }
}
dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }
-- DSA with SHA-224
sa-dsaWithSHA224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER dsa-with-sha224
VALUE DSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha224 }
PUBLIC KEYS { pk-dsa }
}
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 }
Turner, et al Expires March 18, 2009 [Page 29]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- DSA with SHA-256
sa-dsaWithSHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER dsa-with-sha256
VALUE DSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha256 }
PUBLIC KEYS { pk-dsa }
}
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 }
-- ECDSA with SHA-1
sa-ecdsaWithSHA1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER ecdsa-with-SHA1
VALUE ECDSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha1 }
PUBLIC KEYS { pk-ec }
}
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
-- ECDSA with SHA-224
sa-ecdsaWithSHA224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER ecdsa-with-SHA224
VALUE ECDSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha224 }
PUBLIC KEYS { pk-ec }
}
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 1 }
Turner, et al Expires March 18, 2009 [Page 30]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- ECDSA with SHA-256
sa-ecdsaWithSHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER ecdsa-with-SHA256
VALUE ECDSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha256 }
PUBLIC KEYS { pk-ec }
}
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 SHA-384
sa-ecdsaWithSHA384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER ecdsa-with-SHA384
VALUE ECDSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha384 }
PUBLIC KEYS { pk-ec }
}
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 SHA-512
sa-ecdsaWithSHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER ecdsa-with-SHA512
VALUE ECDSA-Sig-Value
PARAMS TYPE NULL ARE absent
HASHES { mda-sha512 }
PUBLIC KEYS { pk-ec }
}
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4 }
Turner, et al Expires March 18, 2009 [Page 31]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
--
-- Signature Values
--
-- DSA
DSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- ECDSA
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
--
-- Message Digest Algorthms (mda-)
--
HashAlgorithms DIGEST-ALGORITHM ::= {
mda-md2 |
mda-md5 |
mda-sha1 |
mda-sha224 |
mda-sha256 |
mda-sha384 |
mda-sha512,
... -- Extensible
}
-- MD-2
mda-md2 DIGEST-ALGORITHM ::= {
IDENTIFIER id-md2
PARAMS TYPE NULL ARE preferredAbsent
}
id-md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }
Turner, et al Expires March 18, 2009 [Page 32]
Internet-Draft ECC SubjectPublicKeyInfo Format September 2008
-- MD-5
mda-md5 DIGEST-ALGORITHM ::= {
IDENTIFIER id-md5
PARAMS TYPE NULL ARE preferredAbsent
}
id-md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }
-- SHA-1
mda-sha1 DIGEST-ALGORITHM ::= {
IDENTIFIER id-sha1
PARAMS TYPE NULL ARE preferredAbsent
}
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
-- SHA-224
-- Parameters are preferred ABSENT
-- mda-sha224
-- SHA-256
-- Parameters are preferred ABSENT
-- mda-sha256
-- SHA-384
-- Parameters are preferred ABSENT
-- mda-sha384
-- Parameters are preferred ABSENT
-- SHA-512
-- Parameters are preferred ABSENT
-- mda-sha512
END
Turner, et al Expires March 18, 2009 [Page 33]
Internet-Draft ECC SubjectPublicKeyInfo Format September 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 March 18, 2009 [Page 34]
Internet-Draft ECC SubjectPublicKeyInfo Format September 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 March 18, 2009 [Page 35]| PAFTECH AB 2003-2026 | 2026-04-23 16:49:53 |