Certificate revocation

Certificate revocation is how PKI marks a certificate untrusted before expiry, checked via CRL and OCSP after key compromise or data changes.

Certificate revocation is how PKI handles a certificate that must stop being trusted before it expires - key compromise, changed data, a subject leaving - tracked through CRL and OCSP. The certificate holder, the issuing certificate authority, or in some cases another party with evidence of a problem such as key compromise can request it. The holder is expected to request revocation without delay if the private key is suspected to be compromised, since every day the certificate remains valid is a window for misuse. Revoking a certificate authority's own certificate invalidates, for new validations, every certificate it issued that has not itself expired - though signatures made before that point can still validate if the signing time is proven, for example with a qualified timestamp - which is why CAs treat their own key material with particular care. Two mechanisms communicate the status: a CRL (Certificate Revocation List) is a periodically published, signed list of the not-yet-expired certificates that a certificate authority has revoked; OCSP (Online Certificate Status Protocol) answers a live query about a single certificate. A verifier finds these services by reading extensions inside the certificate itself: the CRL distribution point extension gives the CRL's location, and the authority information access (AIA) extension gives the OCSP responder's URL. Revocation takes effect from the moment it is published onward - for a qualified certificate under eIDAS this is not retroactive, so a signature or action made before that point can remain valid if the signing time can be proven, for example with a qualified timestamp; without such proof, validation after revocation becomes indeterminate. In X.509 practice more broadly, a CRL entry can carry an earlier revocationDate or invalidityDate, which a relying party may need to take into account when validating older signatures.

Every validation should include a revocation check at the relevant point in time, though how a verifier handles a stale or unreachable status response varies: some fail closed on an unreachable CRL or OCSP responder (a hard-fail policy), while others accept the most recent status within its validity window as a grace period (a soft-fail policy) - which approach applies depends on the verifier's own validation policy. A QTSP must run this status service reliably - it is part of the audited service. Under eIDAS 2.0, the EUDI Wallet ecosystem uses a related mechanism, set out in the ARF and in implementing acts under eIDAS 2.0 - some already adopted, with certain technical details still being finalised: a status list recording whether an attestation or wallet unit has been revoked, checked in a way similar to CRL/OCSP for certificates.