Elliptic Curve Cryptography Subject Public Key Information
updated by
- rfc-8813 — Clarifications for Elliptic Curve Cryptography Subject Public Key Information
updates
- rfc-3279 — Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (24)
The ASN.1 module in this document consolidates all algorithm ASN.1 from RFC 3279, including non-ECC algorithms, so implementers need only use the single updated module rather than combining multiple sources.
The specifiedCurve (SpecifiedECDomain) choice is prohibited in PKIX because allowing arbitrary curve specifications would be a security risk and harm interoperability; only well-known namedCurve OIDs are permitted. Implementers needing specifiedCurve should use the X9.62 ASN.1 module directly.
Two methods for specifying permitted algorithms are defined: id-ecPublicKey allows the key to be used with any ECC algorithm (restricted only by keyUsage), while id-ecDH and id-ecMQV restrict the key to a specific algorithm. This design balances flexibility with explicit algorithm binding to promote interoperability.
Curve naming is inconsistent across standards: secp192r1 equals ansix9p192r1 in X9.62, was called prime192v1 in RFC 3279, and is referred to as P-192 in FIPS 186-3. Similarly secp256r1 was prime256v1. Implementers must account for these aliases.
This document contains a conformant subset of the X9.62 ASN.1 module. A PER-encoded implementation using this module may not produce the same encoding as one using the full X9.62 module; environments requiring PER should use the X9.62 module instead.
For CA certificates using id-ecPublicKey, if keyCertSign or cRLSign is asserted, then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
id-ecPublicKey MUST be supported by CAs and relying parties that implement ECC algorithms.
If elliptic curve domain parameters are not present in the AlgorithmIdentifier, clients MUST reject the certificate.
If the keyUsage extension is present in a certificate indicating id-ecDH or id-ecMQV, the keyAgreement bit MUST be present, and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and cRLSign MUST NOT be present.
Implementations MUST support the uncompressed form of the ECC public key and MAY support the compressed form. The hybrid form from X9.62 MUST NOT be used.
The ECParameters parameter for id-ecPublicKey MUST always be present. The AlgorithmIdentifier within SubjectPublicKeyInfo is the only permitted location for elliptic curve domain parameters in a certificate.
The ECParameters parameter for restricted algorithm identifiers (id-ecDH, id-ecMQV) MUST always be present.
The namedCurve choice in ECParameters MUST be supported. The implicitCurve and specifiedCurve choices MUST NOT be used in PKIX.
The public key MUST be rejected if the first octet of the ECPoint OCTET STRING contains any value other than 0x04 (uncompressed), 0x02, or 0x03 (compressed forms).
ECParameters is a CHOICE with three options: namedCurve (OBJECT IDENTIFIER naming a well-known curve), implicitCurve (NULL, inherited), and specifiedCurve (SpecifiedECDomain). Only namedCurve is permitted in PKIX; implicitCurve and specifiedCurve MUST NOT be used.
The ASN.1 module PKIX1Algorithms2008 (OID arc pkix/id-mod/45) is defined in Appendix A, providing a complete, self-contained module for all algorithm identifiers including RSA, DSA, DH, KEA, ECC signature and key agreement algorithms, named curves, and associated signature value types.
The document publishes OIDs for fifteen NIST-recommended curves: secp192r1, sect163k1, sect163r2, secp224r1, sect233k1, sect233r1, secp256r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, and sect571r1.
The SubjectPublicKeyInfo type in X.509 certificates is a SEQUENCE containing an AlgorithmIdentifier (algorithm OID plus optional parameters) and a subjectPublicKey BIT STRING carrying the ECC public key.
Three ECC algorithm identifiers are defined: id-ecPublicKey (unrestricted use, also used for ECDSA), id-ecDH (restricted to ECDH key agreement), and id-ecMQV (restricted to ECMQV key agreement).
For interoperability, specific combinations are RECOMMENDED: 192-bit key with SHA-256/secp192r1 (80-bit security), 224-bit/SHA-256/secp224r1 (112-bit), 256-bit/SHA-256/secp256r1 (128-bit), 384-bit/SHA-384/secp384r1 (192-bit), and 521-bit/SHA-512/secp521r1 (256-bit).
The bits of security provided by ECC key size, hash algorithm, and named curve should be roughly equivalent. A table maps ECDSA key sizes (160–512+ bits) to appropriate hash algorithms and recommended NIST curves at security levels of 80, 112, 128, 192, and 256 bits.
There are security risks with keys not associated with well-known, widely-reviewed curves: the curve may not satisfy the MOV condition or may be vulnerable to the Anomalous attack. ECC public key validation must verify arithmetic properties to confirm the key is in the correct (sub)group per the associated domain parameters.
Using a larger hash than necessary and truncating it wastes processing power, which is especially important on constrained devices. Signers should use a hash function that provides exactly the desired output size.
ECPoint is encoded as an OCTET STRING. The first octet is a compression indicator: 0x04 for uncompressed, 0x02 or 0x03 for compressed. The OCTET STRING is then mapped bit-for-bit into the BIT STRING subjectPublicKey field.