Internet X.509 Public Key Infrastructure Certificate and CRL Profile
obsoleted by
- rfc-3280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (30)
X.509 v3 extensions replace the rigid RFC 1422 PEM hierarchy (which required a fixed IPRA root, name subordination rules, and a priori knowledge of PCAs) by encoding policy and constraint information directly in certificates. This allows certification paths to start at any trusted CA, name constraints to be explicitly stated or omitted, and policy mappings to replace PCAs, enabling automated chain processing.
Legacy implementations embed RFC 822 email addresses in the subject DN as an EmailAddress attribute of type IA5String. New certificates MUST use rfc822Name in subjectAltName for email identities; simultaneous inclusion of EmailAddress in the subject DN is deprecated but permitted for backward compatibility.
Legacy implementations may encode ISO 8859-1 (Latin1String) characters but tag them as TeletexString. Implementations processing TeletexString SHOULD be prepared to handle the entire ISO 8859-1 character set. Attribute values encoded in different string types (e.g., PrintableString vs. BMPString) may be treated as representing different strings.
A certificate-using system MUST reject a certificate if it encounters a critical extension it does not recognize. A non-critical extension may be ignored if it is not recognized.
All certificates issued after December 31, 2003 MUST use UTF8String encoding for DirectoryString fields in distinguished names. Until that date, CAs must choose PrintableString (if sufficient), then BMPString, then UTF8String.
Certificate validity dates through the year 2049 MUST be encoded as UTCTime; dates in 2050 or later MUST be encoded as GeneralizedTime.
Conforming CAs MUST support key identifiers, basic constraints, key usage, and certificate policies extensions. Applications MUST recognize all extensions that must or may be marked critical: key usage, certificate policies, subject alternative name, basic constraints, name constraints, policy constraints, and extended key usage.
GeneralizedTime values MUST be expressed in GMT (Zulu) and MUST include seconds (format YYYYMMDDHHMMSSZ). GeneralizedTime values MUST NOT include fractional seconds.
If the subject is a CA, the subject field MUST be populated with a non-empty DN matching the issuer field in all certificates it issues. If subject naming is present only in subjectAltName, the subject field MUST be an empty sequence and subjectAltName MUST be critical.
The Basic Constraints extension MUST appear as a critical extension in all CA certificates. pathLenConstraint MUST be greater than or equal to zero where present. This extension SHOULD NOT appear in end-entity certificates.
The certificate serial number MUST be unique for each certificate issued by a given CA; the issuer name and serial number together uniquely identify a certificate.
The issuer field MUST contain a non-empty distinguished name. Certificate users MUST process issuer and subject DN fields to perform name chaining for certification path validation by matching the issuer DN in one certificate against the subject name in a CA certificate.
The keyIdentifier field of authorityKeyIdentifier MUST be included in all certificates generated by conforming CAs to facilitate chain building, except in self-signed certificates. This extension MUST NOT be marked critical.
The signatureAlgorithm field in the outer Certificate sequence MUST contain the same algorithm identifier as the signature field inside TBSCertificate. These two fields must be identical.
The Subject Key Identifier extension MUST appear in all conforming CA certificates. Its value MUST equal the keyIdentifier placed in the authorityKeyIdentifier extension of certificates issued by the subject CA. This extension MUST NOT be marked critical.
UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (format YYMMDDHHMMSSZ). YY >= 50 is interpreted as 19YY; YY < 50 is interpreted as 20YY.
When subjectAltName contains an iPAddress it MUST be stored in network byte order: exactly 4 octets for IPv4 (RFC 791) or exactly 16 octets for IPv6 (RFC 1883). DNS names MUST use preferred name syntax per RFC 1034 as IA5String in dNSName; email addresses MUST use rfc822Name.
The Authority Information Access extension (id-pe arc) provides information on how to access services for the issuing CA, including OCSP responder locations and CA issuer certificate retrieval URIs. It is a private Internet extension defined for use in both end-entity and CA certificates.
The Authority Key Identifier extension (OID id-ce 35) identifies the public key corresponding to the private key used to sign a certificate, supporting disambiguation when an issuer has multiple signing keys. It contains optional keyIdentifier (OCTET STRING), authorityCertIssuer (GeneralNames), and authorityCertSerialNumber fields.
The Basic Constraints extension (OID id-ce 19) identifies whether the subject is a CA (cA BOOLEAN DEFAULT FALSE) and specifies the maximum depth of a valid certification path via pathLenConstraint (INTEGER). A pathLenConstraint of zero means only an end-entity certificate may follow.
The Certificate Policies extension (OID id-ce 32) contains a sequence of PolicyInformation terms, each comprising a CertPolicyId OID and optional qualifiers. Two defined qualifier types are the CPS Pointer (URI to Certification Practice Statement) and User Notice (display text up to 200 characters).
The Key Usage extension (OID id-ce 15) defines the intended purpose of the key as a BIT STRING with named bits: digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8). When used, this extension SHOULD be marked critical.
The Name Constraints extension (used only in CA certificates) defines permittedSubtrees and excludedSubtrees of GeneralSubtrees within which all subject names in subsequent path certificates must fall. It applies to subject DNs and subject alternative names; any name matching an excludedSubtrees entry is invalid regardless of permittedSubtrees. This extension MUST be critical.
The Policy Mappings extension (OID id-ce 33), used only in CA certificates, lists pairs of issuerDomainPolicy and subjectDomainPolicy OIDs indicating that the issuing CA considers its policy equivalent to the subject CA's policy. This extension MUST be non-critical.
The Subject Alternative Name extension (OID id-ce 17) binds additional identity forms to the certificate subject using GeneralName choices: rfc822Name, dNSName, iPAddress, uniformResourceIdentifier, otherName, x400Address, directoryName, ediPartyName, and registeredID. All values must be verified by the CA.
The X.509 v2 CRL structure (CertificateList) contains a signed tbsCertList with issuer name, thisUpdate, optional nextUpdate, and a list of revoked certificate entries each identified by serial number, revocation date, and optional entry extensions (reasonCode, invalidityDate, certificateIssuer). CRL extensions include Authority Key Identifier, CRL Number, Delta CRL Indicator, and Issuing Distribution Point.
Private key compromise, name change, or change of affiliation with a CA requires certificate revocation. Relying parties must obtain a suitably-recent CRL (typically the most recent) and verify the certificate serial number is absent. CRL-based revocation granularity is limited to the CRL issuance period (up to one hour, day, or week).
Security of the Internet PKI depends on the integrity of CA private keys and correct path validation. Marking extensions such as key usage, basic constraints, and name constraints as critical is essential; implementations that ignore unrecognized critical extensions are explicitly prohibited to prevent policy bypass.
The certificate path validation algorithm (Section 6.1) processes certificates from trust anchor to end entity, maintaining state variables: valid_policy_tree, permitted_subtrees, excluded_subtrees, explicit_policy, and path_length. For each certificate it checks signature, validity period, revocation status, name chaining, and extension constraints, yielding an accept/reject decision and the set of valid policies.
The X.509 v3 Certificate is a DER-encoded SEQUENCE of tbsCertificate (TBSCertificate), signatureAlgorithm (AlgorithmIdentifier), and signatureValue (BIT STRING). TBSCertificate contains version, serialNumber, signature, issuer, validity, subject, subjectPublicKeyInfo, optional unique identifiers, and optional extensions.