RFC 3279

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

📅 published May 2002, from ietf

RFC 3279 💖 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

okay bestie, this is RFC 3279 and it's giving main character energy 💅

It came out in April 2002 through the Network Working Group as a Standards Track document. Three authors wrote it: W. Polk from NIST, R. Housley from RSA Laboratories, and L. Bassham from NIST again 🧚. It obsoletes RFC 2528, and the header doesn't list anything it updates. 🌸

Status of this Memo ✨

Okay so this is the part where they explain what kind of doc this is. It's an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🫶 If you want to know where this protocol sits in the official standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so it's public, bestie 🌈

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

This doc specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation lists (CRLs), and certificates carry the public key of the named subject 🔥

Table of Contents 🎀

1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10
2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
5  Security Considerations . . . . . . . . . . . . . . . . .  25
6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27

1. Introduction ✨

Okay, first things first, the key words. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way [RFC 2119] describes them 📚

This doc specifies algorithm identifiers and ASN.1 [X.660] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). It supplements [RFC 3280], the "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile." Implementations of this specification MUST also conform to RFC 3280 💅

This spec defines what goes in the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields inside Internet X.509 certificates and CRLs. The fields are the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields, bestie 🦋

It also identifies one-way hash functions for generating digital signatures. These algorithms get used together with digital signature algorithms, so they're a package deal 🌸

This spec describes how digital signatures get encoded for these algorithms:

  • Rivest-Shamir-Adelman (RSA);
  • Digital Signature Algorithm (DSA); and
  • Elliptic Curve Digital Signature Algorithm (ECDSA).

It also specifies what goes in the subjectPublicKeyInfo field of Internet X.509 certificates. For each algorithm, it gives the right options for the keyUsage extension 🔑 And it describes encoding formats for public keys used with these algorithms:

  • Rivest-Shamir-Adelman (RSA);
  • Digital Signature Algorithm (DSA);
  • Diffie-Hellman (DH);
  • Key Encryption Algorithm (KEA);
  • Elliptic Curve Digital Signature Algorithm (ECDSA); and
  • Elliptic Curve Diffie-Hellman (ECDH).

2. Algorithm Support 🦋

This section covers the cryptographic algorithms that can be used with the Internet X.509 certificate and CRL profile [RFC 3280]. It goes over the one-way hash functions and digital signature algorithms that can sign certificates and CRLs, and it names the object identifiers (OIDs) for public keys inside a certificate. Iconic 🔥

Conforming CAs and applications MUST, at a minimum, support digital signatures and public keys for one of the specified algorithms. When they use any of the algorithms in this spec, conforming CAs and applications MUST support them as described. No skipping the rules, bestie 💀

2.1. One-way Hash Functions 🌈

This section names the one-way hash functions for the Internet X.509 PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423], and MD5 shows up in other legacy apps. That's why MD2 and MD5 are included in this profile 🙈 The data that gets hashed for certificate and CRL signing is fully described in [RFC 3280].

2.1.1. MD2 One-way Hash Function 🍓

MD2 was developed by Ron Rivest for RSA Security. RSA Security has recently put the MD2 algorithm in the public domain. Before that, RSA Data Security had granted a license to use MD2 for non-commercial Internet Privacy-Enhanced Mail (PEM). MD2 may keep being used with PEM certificates, but SHA-1 is preferred. MD2 makes a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319].

At the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95]. Collisions happen when you can find two different messages that generate the same message digest. A checksum operation in MD2 is the only thing left standing between the attack and success. So the use of MD2 for new applications is discouraged. It's still reasonable to use MD2 to verify existing signatures, because being able to find collisions in MD2 doesn't let an attacker find new messages that match a previously computed hash value 😭

2.1.2. MD5 One-way Hash Function 💜

MD5 was developed by Ron Rivest for RSA Security. RSA Security has placed the MD5 algorithm in the public domain. MD5 makes a 128-bit "hash" of the input. MD5 is fully described in [RFC 1321].

Den Boer and Bosselaers [DB94] found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It's still reasonable to use MD5 to verify existing signatures 🫶

2.1.3. SHA-1 One-way Hash Function ⭐

SHA-1 was developed by the U.S. Government. SHA-1 makes a 160-bit "hash" of the input. SHA-1 is fully described in [FIPS 180-1]. RFC 3174 [RFC 3174] also describes SHA-1, and it provides an implementation of the algorithm 🎀

2.2. Signature Algorithms 🔥

Certificates and CRLs that follow [RFC 3280] may be signed with any public key signature algorithm. The certificate or CRL says which algorithm was used through an algorithm identifier that shows up in the signatureAlgorithm field inside the Certificate or CertificateList. That algorithm identifier is an OID and may have optional parameters attached. This section names the algorithm identifiers and parameters that MUST be used in the signatureAlgorithm field in a Certificate or CertificateList, so pay attention 👑

Signature algorithms are always used together with a one-way hash function 🧚

This section names the OIDs for RSA, DSA, and ECDSA. The contents of the parameters component vary for each algorithm, so the details are given for each one 🦋

The data to be signed (for example, the one-way hash function output value) gets formatted for the signature algorithm being used. Then a private key operation (for example, RSA encryption) is performed to make the signature value. That signature value is ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signature field 💖

2.2.1. RSA Signature Algorithm 🌸

The RSA algorithm is named after its inventors: Rivest, Shamir, and Adleman. This profile includes three signature algorithms based on the RSA asymmetric encryption algorithm. These signature algorithms combine RSA with either the MD2, MD5, or SHA-1 one-way hash functions 🌈

The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding conventions described in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 hash algorithm.

The RSA signature algorithm, as specified in PKCS #1 [RFC 2313], includes a data encoding step. In that step, the message digest and the OID for the one-way hash function used to compute the digest get combined. When doing the data encoding step, the md2, md5, and id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way hash functions, respectively 🔑

md2  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) US(840) rsadsi(113549)
     digestAlgorithm(2) 2 }

md5  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) US(840) rsadsi(113549)
     digestAlgorithm(2) 5 }

id-sha1  OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) oiw(14) secsig(3)
     algorithms(2) 26 }

The signature algorithm with MD2 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As PKCS #1 [RFC 2313] defines it, the ASN.1 OID for this signature algorithm is:

md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-1(1) 2  }

The signature algorithm with MD5 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As PKCS #1 [RFC 2313] defines it, the ASN.1 OID for this signature algorithm is:

md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-1(1) 4  }

The ASN.1 object identifier for this signature algorithm is:

sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-1(1) 5  }
When any of these three OIDs shows up inside the ASN.1 type AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL. Don't skip this one, bestie 🚨

The RSA signature generation process and how the result gets encoded are described in detail in PKCS #1 [RFC 2313] 🎀

2.2.2. DSA Signature Algorithm ✨

Okay so DSA (the Digital Signature Algorithm) lives in the Digital Signature Standard (DSS) 🔐. The U.S. Government came up with it, and it's always paired with the SHA-1 one-way hash function. The full deets are in [FIPS 186]. Here's the ASN.1 OID that names it:

id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57 (10040)
     x9cm(4) 3 }

When the id-dsa-with-sha1 algorithm identifier shows up as the algorithm field in an AlgorithmIdentifier, the encoding SHALL omit the parameters field. 💅 So the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1. No extras, periodt.

The DSA parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to verifying the signature. 🫶

When you sign with DSA, the algorithm spits out two values, usually called r and s. To make it easy to move those two values around as one signature, they SHALL be ASN.1 encoded using this structure:

Dss-Sig-Value  ::=  SEQUENCE  {
        r       INTEGER,
        s       INTEGER  }

2.2.3. ECDSA Signature Algorithm 🦋

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. The ASN.1 object identifiers used to name ECDSA all live in this arc:

ansi-X9-62  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 }

id-ecSigType OBJECT IDENTIFIER  ::=  {
     ansi-X9-62 signatures(4) }

ECDSA gets paired with the SHA-1 one-way hash function. The ASN.1 object identifier for ECDSA with SHA-1 is:

ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
     id-ecSigType 1 }

When the ecdsa-with-SHA1 algorithm identifier shows up as the algorithm field in an AlgorithmIdentifier, the encoding MUST omit the parameters field. 🙈 That means the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1. Non-negotiable, bestie.

The elliptic curve parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to verifying the signature. ⭐

When signing, ECDSA also produces two values, r and s. To transfer them as one signature, they MUST be ASN.1 encoded using this structure:

Ecdsa-Sig-Value  ::=  SEQUENCE  {
     r     INTEGER,
     s     INTEGER  }

2.3. Subject Public Key Algorithms 🌸

Certificates that conform to [RFC 3280] can carry a public key for any public key algorithm. ✨ The certificate tells you which algorithm it is through an algorithm identifier, and that identifier is an OID plus optional parameters.

This section picks out the preferred OIDs and parameters for RSA, DSA, Diffie-Hellman, KEA, ECDSA, and ECDH. Conforming CAs MUST use the identified OIDs when they issue certificates containing public keys for these algorithms. 👑 Conforming applications that support any of these algorithms MUST, at a minimum, recognize the OID identified in this section. Gotta know your OIDs!

2.3.1. RSA Keys 🔑

The OID rsaEncryption identifies RSA public keys.

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
               rsadsi(113549) pkcs(1) 1 }

rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

The rsaEncryption OID is meant to go in the algorithm field of an AlgorithmIdentifier value. The parameters field MUST have ASN.1 type NULL for this algorithm identifier. 🧚

The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:

RSAPublicKey ::= SEQUENCE {
   modulus            INTEGER,    -- n
   publicExponent     INTEGER  }  -- e

Here, modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is the value of the BIT STRING subjectPublicKey. 🍓

This OID is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the key MAY be indicated in the key usage field (see [RFC 3280]). Using one key for both signing and encryption is not recommended, but it's not forbidden. 🤷‍♀️

If the keyUsage extension is present in an end entity certificate that conveys an RSA public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyEncipherment; and
dataEncipherment.

If the keyUsage extension is present in a CA or CRL issuer certificate that conveys an RSA public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.

However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment SHOULD NOT be present. 💀 Main character energy is knowing when to keep your roles separate.

2.3.2. DSA Signature Keys 💜

The Digital Signature Algorithm (DSA) is defined in the Digital Signature Standard (DSS) [FIPS 186]. The DSA OID this profile supports is:

id-dsa OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

The id-dsa algorithm syntax includes optional domain parameters, usually called p, q, and g. When they're left out, the parameters component MUST be omitted entirely. So the AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa. 🎀

If the DSA domain parameters are present in the subjectPublicKeyInfo AlgorithmIdentifier, they're included using this structure:

Dss-Parms  ::=  SEQUENCE  {
    p             INTEGER,
    q             INTEGER,
    g             INTEGER  }

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place in a certificate where the parameters may be used. 🦋 If the DSA algorithm parameters are left out of the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key.

If the DSA domain parameters are left out of the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the subject's DSA domain parameters are distributed by other means. 🗺️

If the subjectPublicKeyInfo AlgorithmIdentifier omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the subject's DSA parameters aren't available through other means, then clients MUST reject the certificate. 🚫 Not vibing, not accepting it.

The DSA public key MUST be ASN.1 DER encoded as an INTEGER. This encoding shall be used as the contents (the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.

DSAPublicKey ::= INTEGER -- public key, Y

If the keyUsage extension is present in an end entity certificate that conveys a DSA public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;

If the keyUsage extension is present in a CA or CRL issuer certificate that conveys a DSA public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.

2.3.3. Diffie-Hellman Key Exchange Keys 🌈

The Diffie-Hellman OID this profile supports is defined in [X9.42].

dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) ansi-x942(10046) number-type(2) 1 }

The dhpublicnumber OID is meant to go in the algorithm field of an AlgorithmIdentifier value. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BY algorithm, has the ASN.1 type DomainParameters for this algorithm. 🧠

DomainParameters ::= SEQUENCE {
      p       INTEGER, -- odd prime, p=jq +1
      g       INTEGER, -- generator, g
      q       INTEGER, -- factor of p-1
      j       INTEGER OPTIONAL, -- subgroup factor
      validationParms  ValidationParms OPTIONAL }

ValidationParms ::= SEQUENCE {
      seed             BIT STRING,
      pgenCounter      INTEGER }

Here's what the fields of type DomainParameters mean:

  • p identifies the prime p defining the Galois field;
  • g specifies the generator of the multiplicative subgroup of order g;
  • q specifies the prime factor of p-1;
  • j optionally specifies the value that satisfies the equation p=jq+1 to support the optional verification of group parameters; 🔍
  • seed optionally specifies the bit string parameter used as the seed for the domain parameter generation process; and
  • pgenCounter optionally specifies the integer value output as part of the of the domain parameter prime generation process.

If either of the domain parameter generation components (pgenCounter or seed) is provided, the other MUST be present as well. 👯‍♀️ They come as a pair or not at all.

The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER. This encoding shall be used as the contents (the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.

DHPublicKey ::= INTEGER -- public key, y = g^x mod p

If the keyUsage extension is present in a certificate that conveys a DH public key, the following values may be present:

keyAgreement;
encipherOnly; and
decipherOnly.

If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. ✨ The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly. Absolutely not, that's a hard no 🙅‍♀️

2.3.4 KEA Public Keys 🦋

okay so this section is all about the preferred OID and parameters for putting a KEA public key into a certificate 💅 KEA (Key Exchange Algorithm) is a key agreement algorithm, and the big rule is that two parties can make a "pairwise key" if and only if they share the same KEA parameters ✨ The KEA parameters themselves are not in the certificate. Instead, you stick a domain identifier in the parameters field 🎀

When the SubjectPublicKeyInfo field contains a KEA key, the algorithm identifier and parameters SHALL be as defined in [SDN.701r]:

   id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
          { 2 16 840 1 101 2 1 1 22 }

   KEA-Parms-Id     ::= OCTET STRING

CAs MUST populate the parameters field of the AlgorithmIdentifier within the SubjectPublicKeyInfo field of each certificate containing a KEA public key with an 80-bit parameter identifier (OCTET STRING), also known as the domain identifier. 🌸 The domain identifier gets computed in three steps:

(1) the KEA domain parameters (p, q, and g) are DER encoded using the Dss-Parms structure;

(2) a 160-bit SHA-1 hash is generated from the parameters; and

(3) the 160-bit hash is reduced to 80-bits by performing an "exclusive or" of the 80 high order bits with the 80 low order bits.

The resulting value is encoded so that the most significant byte of the 80-bit value is the first octet in the octet string. The Dss-Parms is provided above in Section 2.3.2. 💖

A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING such that the most significant bit (MSB) of y becomes the MSB of the BIT STRING value field, and the least significant bit (LSB) of y becomes the LSB of the BIT STRING value field. 🧚 This results in the following encoding:

   BIT STRING tag;
   BIT STRING length;
   0 (indicating that there are zero unused bits in the final octet
   of y); and
   BIT STRING value field including y.

The key usage extension may optionally appear in a KEA certificate. 🔑 If a KEA certificate includes the keyUsage extension, only the following values may be asserted:

  • keyAgreement;
  • encipherOnly; and
  • decipherOnly.

If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly. 🙈 Not the keyUsage extension being chaotic about it!

2.3.5 ECDSA and ECDH Keys 🌈

this section is the one for the preferred OID and parameter encoding when you put an ECDSA or ECDH public key in a certificate ✨ ECDSA (Elliptic Curve Digital Signature Algorithm) is defined in [X9.62], and it's basically the elliptic curve math twin of the Digital Signature Algorithm [FIPS 186] 😭 ECDH (Elliptic Curve Diffie Hellman) is a key agreement algorithm defined in [X9.63].

ECDH is the elliptic curve analog of the Diffie-Hellman key agreement algorithm as specified in [X9.42]. ECDSA and ECDH use the same OIDs and parameter encodings, which is so efficient 👑 The ASN.1 object identifiers used to identify these public keys live in the following arc:

ansi-X9-62 OBJECT IDENTIFIER ::=
                          { iso(1) member-body(2) us(840) 10045 }

When certificates contain an ECDSA or ECDH public key, the id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey algorithm identifier is defined as follows: 🎀

  id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }

  id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

This OID is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see [RFC 3280]). Using a single key for both signature and encryption purposes is not recommended, but it's not forbidden 💅

ECDSA and ECDH require certain parameters to go with the public key. 🍓 The parameters may be inherited from the issuer, implicitly included through reference to a "named curve," or explicitly included in the certificate.

   EcpkParameters ::= CHOICE {
     ecParameters  ECParameters,
     namedCurve    OBJECT IDENTIFIER,
     implicitlyCA  NULL }

When the parameters are inherited, the parameters field SHALL contain implictlyCA, which is the ASN.1 value NULL. When parameters are specified by reference, the parameters field SHALL contain the named-Curve choice, which is an object identifier. When the parameters are explicitly included, they SHALL be encoded in the ASN.1 structure ECParameters:

   ECParameters ::= SEQUENCE {
      version   ECPVer,          -- version is always 1
      fieldID   FieldID,         -- identifies the finite field over
                                 -- which the curve is defined
      curve     Curve,           -- coefficients a and b of the
                                 -- elliptic curve
      base      ECPoint,         -- specifies the base point P
                                 -- on the elliptic curve
      order     INTEGER,         -- the order n of the base point
      cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
      }

   ECPVer ::= INTEGER {ecpVer1(1)}

   Curve ::= SEQUENCE {
      a         FieldElement,
      b         FieldElement,
      seed      BIT STRING OPTIONAL }

   FieldElement ::= OCTET STRING

   ECPoint ::= OCTET STRING

The value of FieldElement SHALL be the octet string representation of a field element, following the conversion routine in [X9.62], Section 4.3.3. The value of ECPoint SHALL be the octet string representation of an elliptic curve point, following the conversion routine in [X9.62], Section 4.3.6. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. 🦋

Implementations that support elliptic curve according to this specification MUST support the uncompressed form and MAY support the compressed form.

The components of type ECParameters have the following meanings: 🌸

  • version specifies the version number of the elliptic curve parameters. It MUST have the value 1 (ecpVer1).
  • fieldID identifies the finite field over which the elliptic curve is defined. Finite fields are represented by values of the parameterized type FieldID, constrained to the values of the objects defined in the information object set FieldTypes. Additional detail regarding fieldID is provided below.
  • curve specifies the coefficients a and b of the elliptic curve E. Each coefficient is represented as a value of type FieldElement, an OCTET STRING. seed is an optional parameter used to derive the coefficients of a randomly generated elliptic curve.
  • base specifies the base point P on the elliptic curve. The base point is represented as a value of type ECPoint, an OCTET STRING.
  • order specifies the order n of the base point.
  • cofactor is the integer h = #E(Fq)/n. This parameter is specified as OPTIONAL. However, the cofactor MUST be included in ECDH public key parameters. The cofactor is not required to support ECDSA, except in parameter validation. The cofactor MAY be included to support parameter validation for ECDSA keys. Parameter validation is not required by this specification.
The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the elliptic curve parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using ECDSA, then the certificate issuer's ECDSA parameters apply to the subject's ECDSA key. If the elliptic curve parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the certificate using a signature algorithm other than ECDSA, then clients MUST not make use of the elliptic curve public key. 🚨
   FieldID ::= SEQUENCE {
      fieldType   OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY fieldType }

FieldID is a SEQUENCE of two components, fieldType and parameters. The fieldType contains an object identifier value that uniquely identifies the type contained in the parameters. ✨

The object identifier id-fieldType specifies an arc containing the object identifiers of each field type. It has the following value:

   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

The object identifiers prime-field and characteristic-two-field name the two kinds of fields defined in this Standard. They have the following values:

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

   Prime-p ::= INTEGER    -- Field size p (p in bits)

   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

   Characteristic-two ::= SEQUENCE {
      m           INTEGER,                      -- Field size 2^m
      basis       OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY basis }

The object identifier id-characteristic-two-basis specifies an arc containing the object identifiers for each type of basis for the characteristic-two finite fields. It has the following value:

   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
        characteristic-two-field basisType(1) }

The object identifiers gnBasis, tpBasis and ppBasis name the three kinds of basis for characteristic-two finite fields defined by [X9.62]. They have the following values:

   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

   -- for gnBasis, the value of the parameters field is NULL

   tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }

   -- type of parameters field for tpBasis is Trinomial

   Trinomial ::= INTEGER

   ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

   -- type of parameters field for ppBasis is Pentanomial

   Pentanomial ::= SEQUENCE {
      k1  INTEGER,
      k2  INTEGER,
      k3  INTEGER }

The elliptic curve public key (an ECPoint, which is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curve according to this specification MUST support the uncompressed form and MAY support the compressed form. 🌈

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

  • digitalSignature;
  • nonRepudiation; and
  • keyAgreement.

If the keyAgreement value is present, either of the following values MAY be present:

  • encipherOnly; and
  • decipherOnly.

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly. 🙅‍♀️

If the keyUsage extension is present in a CA certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

  • digitalSignature;
  • nonRepudiation;
  • keyAgreement;
  • keyCertSign; and
  • cRLSign.

As above, if the keyUsage extension asserts keyAgreement, then it MAY assert either encipherOnly and decipherOnly. However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. 💜

3. ASN.1 Module 🧚

okay bestie, this is the whole ASN.1 module, every single line 💅 it's the big list of named IDs and shapes that the rest of the spec points back to, so I'm keeping it byte-for-byte.

PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms(17) }

DEFINITIONS EXPLICIT TAGS ::= BEGIN

-- EXPORTS All;

-- IMPORTS NONE;

--
--   One-way Hash Functions
--

md2  OBJECT IDENTIFIER ::= {
  iso(1) member-body(2) us(840) rsadsi(113549)
  digestAlgorithm(2) 2 }

md5  OBJECT IDENTIFIER ::= {
  iso(1) member-body(2) us(840) rsadsi(113549)
  digestAlgorithm(2) 5 }

id-sha1  OBJECT IDENTIFIER ::= {
  iso(1) identified-organization(3) oiw(14) secsig(3)
  algorithms(2) 26 }

first up: the hash function IDs 🔥 md2, md5, and id-sha1, each with its own OID

--
--   DSA Keys and Signatures
--

-- OID for DSA public key

id-dsa OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

-- encoding for DSA public key

DSAPublicKey ::= INTEGER  -- public key, y

Dss-Parms  ::=  SEQUENCE  {
   p             INTEGER,
   q             INTEGER,
   g             INTEGER  }

-- OID for DSA signature generated with SHA-1 hash

id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

-- encoding for DSA signature generated with SHA-1 hash

Dss-Sig-Value  ::=  SEQUENCE  {
   r       INTEGER,
   s       INTEGER  }

next up is the DSA bit 💜 the key, the parameters, and the signature value all live here

--
--   RSA Keys and Signatures
--

-- arc for RSA public key and RSA signature OIDs

pkcs-1 OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

-- OID for RSA public keys

rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }

-- OID for RSA signature generated with MD2 hash

md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

-- OID for RSA signature generated with MD5 hash

md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

-- OID for RSA signature generated with SHA-1 hash

sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

-- encoding for RSA public key

RSAPublicKey ::= SEQUENCE {
   modulus            INTEGER,    -- n
   publicExponent     INTEGER  }  -- e

RSA time 🦋 the pkcs-1 arc holds the RSA public key OID plus one signature OID per hash

--
--   Diffie-Hellman Keys
--

dhpublicnumber OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-x942(10046)
     number-type(2) 1 }

-- encoding for DSA public key

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 }

Diffie-Hellman era 🌸 yes, the comment above DHPublicKey says "DSA", and yes, that's what the original says too 🙈

--
--   KEA Keys
--

id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
     { 2 16 840 1 101 2 1 1 22 }

KEA-Parms-Id ::= OCTET STRING

KEA is short and sweet 🍓 just the algorithm OID and its parameter ID

--
--   Elliptic Curve Keys, Signatures, and Curves
--

ansi-X9-62 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 }

FieldID ::= SEQUENCE {                    -- Finite field
   fieldType   OBJECT IDENTIFIER,
   parameters  ANY DEFINED BY fieldType }

-- Arc for ECDSA signature OIDS

id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
-- OID for ECDSA signatures with SHA-1

ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }

-- OID for an elliptic curve signature
-- format for the value of an ECDSA signature value

ECDSA-Sig-Value ::= SEQUENCE {
   r     INTEGER,
   s     INTEGER }

-- recognized field type OIDs are defined in the following arc

id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

-- where fieldType is prime-field, the parameters are of type Prime-p

prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime

-- where fieldType is characteristic-two-field, the parameters are
-- of type Characteristic-two

characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

Characteristic-two ::= SEQUENCE {
   m           INTEGER,                   -- Field size 2^m
   basis       OBJECT IDENTIFIER,
   parameters  ANY DEFINED BY basis }

-- recognized basis type OIDs are defined in the following arc

id-characteristic-two-basis OBJECT IDENTIFIER ::= {
     characteristic-two-field basisType(3) }

-- gnbasis is identified by OID gnBasis and indicates
-- parameters are NULL

gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

-- parameters for this basis are NULL

-- trinomial basis is identified by OID tpBasis and indicates
-- parameters of type Pentanomial

tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
-- Trinomial basis representation of F2^m
-- Integer k for reduction polynomial xm + xk + 1

Trinomial ::= INTEGER

-- for pentanomial basis is identified by OID ppBasis and indicates
-- parameters of type Pentanomial

ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 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,
   k2  INTEGER,
   k3  INTEGER }

-- The object identifiers gnBasis, tpBasis and ppBasis name
-- three kinds of basis for characteristic-two finite fields

FieldElement ::= OCTET STRING             -- Finite field element

ECPoint  ::= OCTET STRING                 -- Elliptic curve point

-- Elliptic Curve parameters may be specified explicitly,
-- specified implicitly through a "named curve", or
-- inherited from the CA

EcpkParameters ::= CHOICE {
   ecParameters  ECParameters,
   namedCurve    OBJECT IDENTIFIER,
   implicitlyCA  NULL }

ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
   version   ECPVer,
   fieldID   FieldID,
   curve     Curve,
   base      ECPoint,                -- Base point G
   order     INTEGER,                -- Order n of the base point
   cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n

ECPVer ::= INTEGER {ecpVer1(1)}
Curve  ::= SEQUENCE {
   a     FieldElement,            -- Elliptic curve coefficient a
   b     FieldElement,            -- Elliptic curve coefficient b
   seed  BIT STRING  OPTIONAL }

id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }

id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

the elliptic curve section is the biggest one 🌈 field types, basis types, curve parameters, the whole crew

-- Named Elliptic Curves in ANSI X9.62.

ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }

c-TwoCurve OBJECT IDENTIFIER ::= {
     ellipticCurve characteristicTwo(0) }

c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }

primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }

prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }

END

4. References 📚

bestie, here's the reading list, every single source the spec leans on, with all the details kept 🫶

  • [FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.]
  • [FIPS 186-2] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 27 January 2000. [Supersedes FIPS PUB 186-1 dated 15 December 1998.]
  • [P1363] IEEE P1363, "Standard Specifications for Public-Key Cryptography", 2001.
  • [RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 is not collision free," Presented at Selected Areas in Cryptography '95, May 1995.
  • [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
  • [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
  • [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
  • [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
  • [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January, 1999.
  • [RFC 3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
  • [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [SDN.701r] SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06.
  • [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
  • [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.
  • [X9.42] ANSI X9.42-2000, "Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", December, 1999.
  • [X9.62] X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", January 7, 1999.
  • [X9.63] ANSI X9.63-2001, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", Work in Progress.

5. Security Considerations ✨

okay bestie, security time 🔐😭 this part is SO important, so let's get into it 💅

This specification does not constrain the size of public keys or their parameters for use in the Internet PKI. 🔑 BUT the key size you pick totally affects how strong your cryptographic services are, no cap. Choosing the right key sizes is critical to doing security properly 🫶

This specification also doesn't name any particular elliptic curves for use in the Internet PKI 🦋 However, the curve you choose affects how strong your digital signatures are. Some curves are cryptographically stronger than others, periodt! 💀

Honestly, using "well-known" curves like the "named curves" from ANSI X9.62 is a sound strategy ✨ If you want more info, check out X9.62 Appendix H.1.3, "Key Length Considerations" 📚 and Appendix A.1, "Avoiding Cryptographically Weak Keys" 🙈

Reminder: this document supplements RFC 3280, so the security considerations section of that document applies to this specification as well 🚨 Don't skip it, bestie!

6. Intellectual Property Rights 🎀

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification in this document. 🧾 For more info, check the online list of claimed rights.

The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to apply to implementing or using the technology described here, or on whether any license under such rights might or might not be available. It also doesn't claim it has tried to identify any such rights. 🤷‍♀️ Info about the IETF's procedures for rights in standards-track and standards-related documents can be found in BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementors or users of this specification, can be obtained from the IETF Secretariat 🌸

7. Author Addresses 🧚

Tim Polk NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: tim.polk@nist.gov

Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: rhousley@rsasecurity.com

Larry Bassham NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: lbassham@nist.gov

Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 😭

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from