Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
obsoleted by
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
obsoletes
- rfc-2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
updated by
Extracted elements (28)
CRL-based revocation has an inherent time-granularity limitation equal to the CRL issuance period (minutes to a week), because a revocation is not reliably communicated until the next CRL is issued and distributed. This limitation motivated support for online revocation protocols (defined in companion PKIX specifications), which can reduce the latency to near-zero once a CA accepts a revocation report.
RFC 3280 replaces the rigid RFC 1422 PEM hierarchy (all paths from IPRA, name subordination rule, PCA concept hard-coded into verifiers) with a flexible architecture using X.509 v3 extensions. Policy extensions replace PCAs and name constraint extensions replace the subordination rule, enabling automation and allowing certification paths to start from any locally trusted CA rather than a single global root.
Legacy implementations often encode ISO 8859-1 (Latin1String) character data but tag it as TeletexString. Since TeletexString encodes some characters differently from ISO 8859-1, implementations SHOULD be prepared to handle both encodings under a TeletexString tag.
Name comparison for path validation requires PrintableString attribute values to be compared case-insensitively with leading/trailing whitespace removed and internal whitespace sequences collapsed to a single space. Attribute values encoded in different ASN.1 types (e.g., PrintableString vs BMPString) MAY be treated as different strings, which is a deliberate relaxation from X.500 rules.
A certificate MUST NOT include more than one instance of a particular extension. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; a non-critical unrecognized extension MAY be ignored.
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 prevents relying parties from missing a revocation by using a cached CRL that predates the entry's removal.
All certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString in distinguished names. Prior to that date, conforming CAs MUST choose PrintableString, then BMPString, then UTF8String in preference order; TeletexString and UniversalString SHOULD NOT be used for new subjects.
Applications conforming to this profile MUST recognize the following extensions: key usage, certificate policies, subject alternative name, basic constraints, name constraints, policy constraints, extended key usage, and inhibit any-policy. Applications SHOULD additionally recognize authority key identifier, subject key identifier, and policy mappings.
CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; validity dates in 2050 or later MUST be encoded as GeneralizedTime. This rule avoids the Y2K-style two-digit year ambiguity of UTCTime for dates near or after 2050.
CAs conforming to this profile MUST NOT generate certificates that include a critical private key usage period extension. This extension SHOULD NOT be used within the Internet PKI at all.
Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 4.2.1.2), basic constraints, key usage, and certificate policies extensions. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction.
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 for legacy compatibility is deprecated but permitted.
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) in the format YYYYMMDDHHMMSSZ, MUST include seconds even when zero, and MUST NOT include fractional seconds.
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 field MUST be an empty sequence and the subjectAltName extension MUST be marked critical.
The issuer field MUST contain a non-empty distinguished name. Conforming implementations MUST be prepared to receive issuer and subject names containing country, organization, organizational-unit, DN qualifier, state or province name, common name, serial number, and domainComponent attribute types.
The Key Usage extension MUST appear in certificates containing public keys used to validate digital signatures on other public key certificates or CRLs. When present, it SHOULD be marked critical. If the keyCertSign bit is asserted, the cA bit in basicConstraints MUST also be asserted.
The serial number MUST be a positive integer unique for each certificate issued by a given CA. Certificate users MUST be able to handle serialNumber values up to 20 octets; conformant CAs MUST NOT use serialNumber values longer than 20 octets.
The signatureAlgorithm field in the outer Certificate SEQUENCE MUST contain the same algorithm identifier as the signature field inside TBSCertificate (section 4.1.2.3). This redundancy is required so verifiers need not parse the full TBSCertificate to identify the algorithm.
The subject key identifier extension MUST appear in all conforming CA certificates (where cA is TRUE in basicConstraints). Both the authority key identifier and subject key identifier extensions MUST NOT be marked critical.
UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (format YYMMDDHHMMSSZ). The year field SHALL be interpreted as 19YY when YY >= 50, and as 20YY when YY < 50.
When extensions are used, as expected in this profile, the certificate version MUST be 3 (encoded value 2). Conforming implementations MUST recognize version 3 certificates at minimum; implementations SHOULD be prepared to accept any version certificate.
When subjectAltName contains an rfc822Name, the address MUST use addr-spec format (RFC 822). When it contains an iPAddress, it MUST be stored in network byte order as exactly 4 octets for IPv4 or exactly 16 octets for IPv6. A dNSName of ' ' (space) MUST NOT be used.
The GeneralName CHOICE structure supports nine name forms used in subjectAltName, issuerAltName, and name constraints: otherName, rfc822Name (IA5String), dNSName (IA5String), x400Address (ORAddress), directoryName (Name), ediPartyName (EDIPartyName), uniformResourceIdentifier (IA5String), iPAddress (OCTET STRING), and registeredID (OID).
The Key Usage extension is a BIT STRING with nine named bits: digitalSignature(0), nonRepudiation(1), keyEncipherment(2), dataEncipherment(3), keyAgreement(4), keyCertSign(5), cRLSign(6), encipherOnly(7), decipherOnly(8). The encipherOnly and decipherOnly bits have undefined meaning in the absence of the keyAgreement bit.
The security of the Internet PKI depends on protecting CA private signing keys; compromise enables fraudulent certificate issuance. Implementations MUST reject certificates with unrecognized critical extensions to prevent security policy bypass. Relying parties SHOULD obtain the most recently issued CRL and verify certificate status before relying on any certificate.
The basic certification path validation algorithm (Section 6.1) processes an ordered sequence of n certificates. For each certificate i (1 to n), it verifies signature, validity period, revocation status, and enforces name and policy constraints using state variables including valid_policy_tree, working_public_key, working_issuer_name, and path length counters. The wrap-up procedure at n produces final policy set and public key outputs.
TBSCertificate is a SEQUENCE containing version, serialNumber (INTEGER), signature (AlgorithmIdentifier), issuer (Name), validity (notBefore/notAfter), subject (Name), subjectPublicKeyInfo, optional issuerUniqueID and subjectUniqueID (v2/v3 only), and optional extensions (v3 only). The Extensions field is itself a SEQUENCE of Extension values, each being extnID (OID), critical (BOOLEAN DEFAULT FALSE), and extnValue (OCTET STRING).
The X.509 v3 certificate is a SEQUENCE of three fields: tbsCertificate (TBSCertificate), signatureAlgorithm (AlgorithmIdentifier), and signatureValue (BIT STRING). All data to be signed MUST be encoded using ASN.1 Distinguished Encoding Rules (DER).