RFC 5480
Elliptic Curve Cryptography Subject Public Key Information
RFC 5480: Elliptic Curve Cryptography Subject Public Key Information 🦋
Okay bestie, let's start with the title block 💅 This one comes from the Network Working Group and it's a Standards Track doc, so it's a real standard and not just vibes 🫶 It was published in March 2009. The authors are S. Turner (IECA), D. Brown (Certicom), K. Yiu (Microsoft), R. Housley (Vigil Security), and T. Polk (NIST). It updates RFC 3279 (that's the Updates: 3279 line), so it's basically a glow-up for that older doc ✨
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Abstract 🌸
So the gist is this: the doc lays out the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. It updates Sections 2.3.5 and 5, and it also updates the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. Iconic 👑
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 ................................................3
2.2. Subject Public Key .........................................7
3. Key Usage Bits ..................................................7
4. Security Considerations .........................................8
5. ASN.1 Considerations ...........................................10
6. IANA Considerations ............................................11
7. Acknowledgments ................................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Appendix A. ASN.1 Module ..........................................131. Introduction ✨
Okay so this doc is all about the format of the subjectPublicKeyInfo field in X.509 certificates [PKI] that use Elliptic Curve Cryptography (ECC). It updates RFC 3279 [PKI-ALG]. The encoding formats are specified for public keys used with these ECC algorithms:
- Elliptic Curve Digital Signature Algorithm (ECDSA);
- Elliptic Curve Diffie-Hellman (ECDH) family schemes; and
- Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes.
There are two ways to say which algorithms can be used with the subjectPublicKey 🔥 One way lets the key be used with any ECC algorithm, and the other way limits the key to specific algorithms. For interoperability, the doc says which one Certification Authorities (CAs) that implement ECC algorithms are required to implement, and which one relying parties that claim to process ECC algorithms are required to implement. Main character energy 💅
The ASN.1 [X.680] module in this doc includes ASN.1 for ECC algorithms. It also has ASN.1 for the non-ECC algorithms defined in [PKI-ALG] and [PKI-ADALG], even though the text for those is unaffected. By updating all of the ASN.1 from [PKI-ALG] here, implementers only need to use the module in this document. Less work, more slay 🎀
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 [MUSTSHOULD].
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,
subjectPublicKey BIT STRING
}Here's what the fields in SubjectPublicKeyInfo mean:
algorithmis the algorithm identifier and parameters for the ECC public key.subjectPublicKeyis the ECC public key. See Section 2.2.
The AlgorithmIdentifier type is included for convenience [PKI], and it's defined like this:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}Here's what the fields in AlgorithmIdentifier mean:
algorithmidentifies the cryptographic algorithm with an object identifier. See Section 2.1.parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. See Section 2.1.1.
2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers 🔑
The algorithm field in the SubjectPublicKeyInfo structure [PKI] indicates the algorithm and any associated parameters for the ECC public key (see Section 2.2). Three algorithm identifiers are defined in this document:
id-ecPublicKeyindicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage certificate extension (see Section 3).id-ecPublicKeyMUST be supported. See Section 2.1.1. This value is also included in certificates when a public key is used with ECDSA.id-ecDHindicates that the algorithm that can be used with the subject public key is restricted to the Elliptic Curve Diffie-Hellman algorithm. See Section 2.1.2.id-ecDHMAY be supported.id-ecMQVindicates that the algorithm that can be used with the subject public key is restricted to the Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm. See Section 2.1.2.id-ecMQVMAY be supported.
2.1.1. Unrestricted Algorithm Identifier and Parameters 🧚
The "unrestricted" algorithm identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }The public key (ECPoint) syntax is described in Section 2.2.
The parameter for id-ecPublicKey is as follows and MUST always be present:
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.Here's what the fields in ECParameters mean:
namedCurveidentifies 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.implicitCurveallows the elliptic curve domain parameters to be inherited. This choice MUST NOT be used.specifiedCurve, which is of type SpecifiedECDomain type (defined in [X9.62]), allows all of the elliptic curve domain parameters to be explicitly specified. This choice MUST NOT be used. See Section 5, "ASN.1 Considerations".
Any new choices added to ECParameters need to be coordinated with ANSI X9.
The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place within a certificate where the elliptic curve domain parameters may be located. If the elliptic curve domain parameters are not present, then clients MUST reject the certificate. 🚫
2.1.1.1. Named Curve 🌈
The namedCurve field in ECParameters uses object identifiers to name well-known curves. This document publishes curve identifiers for the fifteen NIST-recommended curves [FIPS186-3]. Other documents can publish other name curve identifiers. The NIST-named curves are:
-- Note that 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 secp256r1 curve was referred to as
-- prime256v1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp256r1 as P-256, 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 }
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 ✨
okay so bestie, two algorithms get the "restricted" label for key agreement: Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 🦋. both are identified by an object identifier AND have parameters 💅. the OID changes depending on which algorithm you're using, but the parameters are always ECParameters, and they MUST always be present (see Section 2.1.1) 🫶
the ECDH algorithm uses this object identifier 🌸:
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }and the ECMQV algorithm uses this one 🎀:
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }2.2. Subject Public Key 🔑
ok the subjectPublicKey from SubjectPublicKeyInfo is the ECC public key 💖. ECC public keys have this syntax:
ECPoint ::= OCTET STRINGimplementations of Elliptic Curve Cryptography under this document MUST support the uncompressed form, and they MAY support the compressed form of the ECC public key 🧚. the hybrid form of the ECC public key from [X9.62] MUST NOT be used 🙈. as specified in [SEC1]:
- the elliptic curve public key (a value of type ECPoint that is an OCTET STRING) gets mapped to a subjectPublicKey (a value of type BIT STRING) like this: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. the conversion routines live in Sections 2.3.1 and 2.3.2 of [SEC1] 🌈
- the first octet of the OCTET STRING tells you whether the key is compressed or uncompressed 🍓. uncompressed is 0x04, and compressed is either 0x02 or 0x03 (see 2.3.3 in [SEC1]). the public key MUST be rejected if any other value shows up in the first octet 💀
3. Key Usage Bits 🎀
if the keyUsage extension is in a Certification Authority (CA) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combo of these values MAY be present 👑:
digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.if the CA certificate keyUsage extension asserts keyAgreement, it MAY assert either encipherOnly or decipherOnly. however, this specification RECOMMENDS that if keyCertSign or cRLSign is present, then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present 🙃
if the keyUsage extension is in an End Entity (EE) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combo of these values MAY be present ✨:
digitalSignature;
nonRepudiation; and
keyAgreement.if the EE certificate keyUsage extension asserts keyAgreement, it MAY assert either encipherOnly or decipherOnly 🦋.
if the keyUsage extension is in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following MUST be present 💅:
keyAgreement;one of the following MAY be present:
encipherOnly; or
decipherOnly.and if the keyUsage extension is in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values MUST NOT be present 🚫:
digitalSignature;
nonRepudiation;
keyTransport;
keyCertSign; and
cRLSign.4. Security Considerations 🔥
this one is serious, bestie, so read it carefully 😭
the security considerations in [PKI-ALG] apply 💜.
when you're implementing ECC in X.509 Certificates and Certificate Revocation Lists (CRLs), there are three algorithm-related choices you have to make for the signatureAlgorithm field in a Certificate or CertificateList 🧐:
- what is the public key size?
- what is the hash algorithm [FIPS180-3]?
- what is the curve?
the CA MUST consider how strong the security is for 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 table below gives comparable minimum bits of security [SP800-57] for the ECDSA key sizes and message digest algorithms, and it also lists curves (see Section 2.1.1.1) for the key sizes 📊:
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 160-223 | SHA-1 | sect163k1
| | SHA-224 | secp163r2
| | SHA-256 | secp192r1
| | SHA-384 |
| | SHA-512 |
---------+----------+------------+-----------
112 | 224-255 | SHA-224 | secp224r1
| | SHA-256 | sect233k1
| | SHA-384 | sect233r1
| | SHA-512 |
---------+----------+------------+-----------
128 | 256-383 | SHA-256 | secp256r1
| | SHA-384 | sect283k1
| | SHA-512 | sect283r1
---------+----------+------------+-----------
192 | 384-511 | SHA-384 | secp384r1
| | SHA-512 | sect409k1
| | | sect409r1
---------+----------+------------+-----------
256 | 512+ | SHA-512 | secp521r1
| | | sect571k1
| | | sect571r1
---------+----------+------------+-----------to promote interoperability, the following choices are RECOMMENDED 🤝:
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 192 | SHA-256 | secp192r1
---------+----------+------------+-----------
112 | 224 | SHA-256 | secp224r1
---------+----------+------------+-----------
128 | 256 | SHA-256 | secp256r1
---------+----------+------------+-----------
192 | 384 | SHA-384 | secp384r1
---------+----------+------------+-----------
256 | 512 | SHA-512 | secp521r1
---------+----------+------------+-----------using a bigger hash and then truncating it wastes processing power you don't need 😩. this matters more on constrained devices 🔋. since the signer doesn't know what environment the recipient will use to validate the signature, it's better to use a hash function that gives you the desired output size, and no more 💅.
there are security risks with keys that aren't tied to well-known, widely reviewed curves 🚨. for example, the curve might not satisfy the Menezes-Okamoto-Vanstone (MOV) condition [X9.62], or it might be vulnerable to the Anomalous attack [X9.62]. on top of that, either a) all of the arithmetic properties of a candidate ECC public key MUST be validated, so 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 arithmetic properties of a candidate ECC public key MUST be validated, so it's in the correct group (but not necessarily the correct subgroup) specified by the associated ECC domain parameters [SP800-56A] 🧠.
as noted in [PKI-ALG], using MD2 and MD5 for new applications is discouraged 🙅. it's still reasonable to use MD2 and MD5 to verify existing signatures 🥹.
5. ASN.1 Considerations 🧩
[X9.62] defines additional options for ECParameters and ECDSA-Sig-Value [PKI-ALG] 🌷. 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 implementation generates a PER [X.691] encoding using the ASN.1 module found in this specification, it might not produce 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 your implementation environment does require PER, then implementation concerns are less likely with the [X9.62] module 🫧.
6. IANA Considerations 🏛️
this document uses a lot of object identifiers to register public key types, elliptic curves, and algorithms 🌈. most are registered in the ANSI X9.62 arc, except for the hash algorithms (which are in the NIST arc) and many of the curves (which are in the Certicom Inc. arc; these curves have been adopted by ANSI and NIST) 💅. there's also an object identifier that identifies the ASN.1 module found in Appendix A. it's 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 🎀.
7. Acknowledgments 💖
the authors wanna thank Stephen Farrell, Alfred Hoenes, Johannes Merkle, Jim Schaad, and Carl Wallace 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, October
2008.
[FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard,
(draft) November 2008.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[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 Group (SECG), "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.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
Information Technology - Abstract Syntax Notation One.8.2. Informative References 📚
Okay, bestie, these are the "go read this if you want the deep lore" links. 🤓💖
- [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", Work in Progress, October 2008.
- [SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation for 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 - Part 1 (Revised), March 2007.
- [X.691] ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002. Information Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules.
Appendix A. ASN.1 Module 🧚✨
Here's the whole ASN.1 module, no cuts. It's giving "every single byte matters" 💅
PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
-- From RFC 4055 [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) }
;
--
-- Message Digest 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 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 4 }
-- SHA-256
-- Parameters are preferred absent
-- 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
-- Parameters are preferred absent
-- 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
-- Parameters are preferred absent
-- id-sha512 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 3 }
--
-- Public Key (PK) Algorithms
--
-- RSA PK Algorithm and Key
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, Key, 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, Key, 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 ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) algorithms(1) 22 }
KEA-Parms-Id ::= OCTET STRING
-- Sec 2.1.1 Unrestricted Algorithm ID, Key, and Parameters
-- (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
-- Parameters for both Restricted and Unrestricted
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.
-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECDH
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- ECPoint ::= OCTET STRING
-- Parameters are ECParameters.
-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECMQV
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
-- ECPoint ::= OCTET STRING
-- Parameters are ECParameters.
--
-- Signature Algorithms
--
-- 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
id-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
id-dsa-with-sha224 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 1 }
-- DSA with SHA-256
-- Parameters are ABSENT
id-dsa-with-sha256 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 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 }
--
-- Signature Values
--
-- DSA
DSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- ECDSA
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
--
-- Named Elliptic Curves
--
-- Note that 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 secp256r1 curve was referred to as prime256v1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp256r1 as P-256, 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 }
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 }
ENDAuthors' 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
EMail: wpolk@nist.gov 🦋
📦 where this page comes from
- ietf: rfc5480 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms