Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Certificates are signed by a trusted CA and distributed over untrusted channels and stored in unsecured repositories because the CA's digital signature and the validity period can be independently verified by any relying party without trusting the distribution medium. This separates integrity from transport trust.

pkix, security

X.509 v3 extensions replace the rigid PEM/RFC 1422 hierarchy (with its IPRA root, PCAs, and name subordination rule) because extensions allow policy information and path constraints to be embedded directly in certificates, enabling automated validation without a priori knowledge of PCAs and supporting cross-certification without structural restrictions.

pkix

A certificate-using system MUST reject a certificate if it encounters a critical extension it does not recognize or cannot process. Non-critical extensions MAY be ignored if not recognized, but MUST be processed if recognized.

pkix, security

A CRL entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. This ensures relying parties can always detect revocation during a certificate's valid lifetime.

pkix, security

CAs conforming to this profile MUST use either PrintableString or UTF8String encoding for DirectoryString in issuer and subject fields, with limited exceptions for backward compatibility with existing PKIs using TeletexString, BMPString, or UniversalString.

pkix

Certificate validity dates through the year 2049 MUST be encoded as UTCTime; dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process both encodings.

pkix

Conforming applications MUST recognize the following extensions: keyUsage, certificatePolicies, subjectAltName, basicConstraints, nameConstraints, policyConstraints, extendedKeyUsage, and inhibitAnyPolicy. Applications SHOULD also recognize authorityKeyIdentifier, subjectKeyIdentifier, and policyMappings.

pkix

Conforming CAs MUST include the keyUsage extension in certificates whose public keys are used to validate signatures on other certificates or CRLs, and SHOULD mark this extension as critical. The keyCertSign bit MUST NOT be set unless the cA bit in basicConstraints is also asserted.

pkix, security

Conforming implementations generating new certificates with electronic mail addresses MUST use rfc822Name in the subjectAltName extension. Simultaneous inclusion of an emailAddress attribute in the subject DN to support legacy implementations is deprecated but permitted.

pkix, email

GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu), MUST include seconds (YYYYMMDDHHMMSSZ), and MUST NOT include fractional seconds.

pkix

If the subject is a CA (cA=TRUE in basicConstraints), the subject field MUST be populated with a non-empty DN matching the issuer field in all certificates issued by that CA. If subject naming is only in subjectAltName, the subject MUST be an empty sequence and subjectAltName MUST be critical.

pkix

Internationalized domain names in dNSName or uniformResourceIdentifier fields of the subjectAltName or issuerAltName extensions MUST use the ACE (Punycode/IDNA) encoding per RFC 3490. Comparisons of such names in path validation MUST use the rules specified in Section 7.2.

pkix, dns

The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs, with the sole exception of self-signed certificates. This extension MUST be marked non-critical.

pkix

The policyConstraints extension MUST be marked as critical (changed from RFC 3280 which permitted non-critical). The policyMappings extension SHOULD be marked as critical (changed from RFC 3280 which required it to be non-critical).

pkix

The serial number MUST be a positive integer, MUST be unique for each certificate issued by a given CA, and MUST NOT exceed 20 octets. Certificate users MUST be able to handle serialNumber values up to 20 octets.

pkix

The signatureAlgorithm field in Certificate MUST contain the same algorithm identifier as the signature field in TBSCertificate. This cross-check ensures the outer signature declaration matches the inner signed data.

pkix, crypto

The subject key identifier extension MUST appear in all conforming CA certificates (those with basicConstraints cA=TRUE). The value MUST match the keyIdentifier placed in the authorityKeyIdentifier of certificates issued by this CA. MUST be marked non-critical.

pkix

UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds in the format YYMMDDHHMMSSZ. Years 50–99 SHALL be interpreted as 19YY; years 00–49 SHALL be interpreted as 20YY.

pkix

When extensions are used, the version field MUST be 3. Conforming implementations MUST recognize version 3 certificates. Conforming CAs MUST NOT generate certificates with unique identifiers.

pkix

The basicConstraints extension identifies whether the subject is a CA (cA BOOLEAN) and optionally constrains the maximum certification path length (pathLenConstraint INTEGER). This extension MUST appear as critical in all CA certificates.

pkix

The certificatePolicies extension contains a SEQUENCE of PolicyInformation entries, each with a CertPolicyId OID and optional qualifiers. Two qualifier types are defined: CPS Pointer (id-qt-cps, a URI) and User Notice (id-qt-unotice, with optional noticeRef and explicitText up to 200 characters).

pkix

The KeyUsage extension is a BIT STRING defining nine purpose bits: digitalSignature(0), nonRepudiation(1), keyEncipherment(2), dataEncipherment(3), keyAgreement(4), keyCertSign(5), cRLSign(6), encipherOnly(7), decipherOnly(8). When present, at least one bit MUST be set.

pkix, crypto

The subjectAltName extension allows subject identities to be expressed as rfc822Name (email), dNSName, uniformResourceIdentifier, iPAddress, registeredID, or directoryName. Conforming implementations MUST support rfc822Name, dNSName, and directoryName forms.

pkix

Name ambiguity arises when multiple distinct entities share the same distinguished name across different CAs. Relying parties MUST NOT assume that a DN uniquely identifies an entity across all CAs; policy and trust anchor context are required to correctly resolve identity.

pkix, security

The CRL revocation method has time-granularity limited to the CRL issuance period; a revoked certificate may remain apparently valid until the next scheduled CRL update (up to hours or days). On-line status protocols such as OCSP reduce this latency but impose trust requirements on the validation service.

pkix, security

Using HTTPS or similar protected schemes in CRL distribution points, authority information access, or subject information access extensions creates a circular dependency: validating the certificate requires fetching a resource that itself requires certificate validation. Implementations must avoid this bootstrapping problem.

pkix, security

The basic path validation algorithm processes a sequence of n certificates. For each certificate i (1 to n), it verifies the signature, validity period, name chaining (issuer[i] == subject[i-1]), revocation status, and extension constraints. States track: valid_policy_tree, working_public_key, working_issuer_name, explicit_policy, inhibit_anyPolicy, and policy_mapping inhibit counters.

pkix, security

TBSCertificate is a SEQUENCE containing version, serialNumber, signature (AlgorithmIdentifier), issuer (Name), validity (notBefore/notAfter), subject (Name), subjectPublicKeyInfo, optional issuerUniqueID and subjectUniqueID (v2/v3 only), and optional extensions (v3 only).

pkix, crypto

The X.509 v2 CRL (CertificateList) is a SEQUENCE of tbsCertList (TBSCertList), signatureAlgorithm (AlgorithmIdentifier), and signatureValue (BIT STRING). TBSCertList includes version, signature, issuer, thisUpdate, optional nextUpdate, optional revokedCertificates list, and optional extensions.

pkix, security

The X.509 v3 Certificate is a DER-encoded SEQUENCE of three fields: tbsCertificate (TBSCertificate), signatureAlgorithm (AlgorithmIdentifier), and signatureValue (BIT STRING). The signature is computed over the DER encoding of tbsCertificate.

pkix, crypto, security