Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
updated by
- rfc-4055 — 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-4491 — Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- rfc-5480 — Elliptic Curve Cryptography Subject Public Key Information
- rfc-5758 — Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
- rfc-8692 — Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs
Extracted elements (26)
DSA parameters (p, q, g) may be omitted from SubjectPublicKeyInfo when they can be inherited from the issuer's certificate, allowing smaller certificates when the CA signed the subject using DSA.
MD2 and MD5 are included in this profile despite SHA-1 being preferred because PEM uses MD2 for certificates (RFC 1422/1423) and MD5 is used in other legacy applications. Both are discouraged for new applications but remain valid for verifying existing signatures.
This specification supplements RFC 3280 and implementations MUST also conform to that profile. The security considerations of RFC 3280 apply to this specification as well.
Conforming CAs MUST use the identified OIDs when issuing certificates containing public keys for RSA, DSA, DH, KEA, ECDSA, and ECDH algorithms. Conforming applications supporting any of these algorithms MUST, at a minimum, recognize the OID.
For EC certificates, if keyCertSign or cRLSign is present, keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly simultaneously.
For KEA public keys, CAs MUST populate the parameters field of AlgorithmIdentifier with an 80-bit domain identifier (OCTET STRING) computed as: DER-encode Dss-Parms, SHA-1 hash it to 160 bits, then XOR the high 80 bits with the low 80 bits.
For RSA CA/CRL-issuer certificates with keyUsage, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment SHOULD NOT be present.
If DSA domain parameters are omitted from SubjectPublicKeyInfo, the CA signed with a non-DSA algorithm, and the subject's DSA parameters are not available through other means, then clients MUST reject the certificate.
If either pgenCounter or seed domain parameter generation components is provided, the other MUST also be present. For DH keyUsage, the extension MUST assert keyAgreement and MUST NOT assert both encipherOnly and decipherOnly.
Implementations of this specification MUST also conform to RFC 3280. Conforming CAs and applications MUST, at a minimum, support digital signatures and public keys for one of the specified algorithms.
The cofactor field MUST be included in ECDH public key parameters. The ECParameters version MUST have the value 1 (ecpVer1). If EC parameters are implicitlyCA and the CA signed with a non-ECDSA algorithm, clients MUST NOT use the elliptic curve public key.
When any of the three RSA signature OIDs (md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption) appears within an AlgorithmIdentifier, the parameters component SHALL be the ASN.1 type NULL.
When certificates contain an ECDSA or ECDH public key, the id-ecPublicKey algorithm identifier MUST be used. Implementations MUST support the uncompressed form of EC points and MAY support the compressed form.
When id-dsa-with-sha1 appears as the algorithm field in an AlgorithmIdentifier, the encoding SHALL omit the parameters field; the AlgorithmIdentifier SHALL be a SEQUENCE of one component.
When the ecdsa-with-SHA1 algorithm identifier appears in an AlgorithmIdentifier, the encoding MUST omit the parameters field; the AlgorithmIdentifier SHALL be a SEQUENCE of one component.
Named elliptic curves from ANSI X9.62 are defined under two arcs: c-TwoCurve (20 characteristic-two curves including c2pnb163v1 through c2tnb431r1) and primeCurve (7 prime-field curves including prime192v1 through prime256v1).
Three RSA signature algorithm OIDs are defined: md2WithRSAEncryption (pkcs-1 2), md5WithRSAEncryption (pkcs-1 4), and sha1WithRSAEncryption (pkcs-1 5). DSA uses id-dsa-with-sha1; ECDSA uses ecdsa-with-SHA1.
MD2 is subject to a near-collision attack (Rogier and Chauvaud, 1995) where only the checksum step prevents full collisions; its use for new applications is discouraged. MD5 has known pseudo-collisions; its use for new applications is also discouraged. Both remain acceptable only for verifying existing signatures.
This specification does not constrain public key sizes or parameters; selection of appropriate key sizes is critical for security. The particular elliptic curve selected also impacts signature strength — some curves are cryptographically stronger than others. Use of well-known named curves from ANSI X9.62 is recommended.
Diffie-Hellman public key MUST be ASN.1 encoded as DHPublicKey ::= INTEGER (y = g^x mod p). Domain parameters use DomainParameters ::= SEQUENCE { p, g, q, j OPTIONAL, validationParms OPTIONAL } identified by OID dhpublicnumber.
DSA public key MUST be ASN.1 DER encoded as DSAPublicKey ::= INTEGER (the value Y), used as the contents of the BIT STRING subjectPublicKey in SubjectPublicKeyInfo. Domain parameters use Dss-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER }.
DSA signature values r and s SHALL be ASN.1 encoded as Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } and conveyed as a BIT STRING in the certificate signature field.
EC public key parameters use EcpkParameters ::= CHOICE { ecParameters ECParameters, namedCurve OBJECT IDENTIFIER, implicitlyCA NULL }. ECParameters includes version (must be ecpVer1=1), fieldID, curve (a, b coefficients), base point, order, and optional cofactor.
ECDSA signature values r and s MUST be ASN.1 encoded as Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } conveyed as a BIT STRING.
KEA public key y is conveyed in subjectPublicKey BIT STRING with MSB of y as MSB of the BIT STRING value, LSB of y as LSB; preceded by BIT STRING tag, length, and 0 (zero unused bits indicator).
RSA public keys MUST be encoded as RSAPublicKey ::= SEQUENCE { modulus INTEGER, publicExponent INTEGER }; the DER-encoded value is placed in the BIT STRING subjectPublicKey field. The rsaEncryption OID parameters field MUST have ASN.1 type NULL.