A focused operating guide for CA revocation request intake, status-service publication, CRL cadence, OCSP support, and consistency evidence under ETSI EN 319 411-1.
Based on ETSI EN 319 411-1 clauses 6.2.4, 6.3.9, 6.3.10, and 6.6, with EN 319 401 evidence-record support.
Structured answer sets in this page tree.
Cited legal and guidance references.
Document who can request revocation, how requests are confirmed and authenticated, when the 24-hour maximum starts, how each reaches relying parties, and how CRL and OCSP remain consistent. Then branch explicitly for short-term certificates and certificates carrying the validity assured extension; their revocation-management or status-service treatment can differ from the general rule. This page applies EN 319 411-1 V1.5.1. Its EN 319 401 reference is non-specific, so clause 2.1 makes the latest edition applicable; record the EN 319 401 edition and assessment date used.
The (CPS) needs to state who can submit revocation requests or event reports, how they are submitted, what confirmation is required, whether certificates can be suspended or revoked, which mechanism distributes status information, and the maximum delays before relying parties can see the status change. Internal ticket procedures should implement those published practices.
The operating design should separate revocation management from revocation status distribution. Revocation management decides the action to take on a request or event report; the status service exposes the resulting certificate status to relying parties through OCSP, CRL, or both.
EN 319 411-1 requires timely revocation based on authorized and validated requests, and it also names events that require revocation of non-expired certificates. The operational file should therefore prove the full path: request or event report received, authenticated, checked against the authorized source, decided by the responsible trusted role, and converted into updated status information.
If suspension is available, keep it distinct from definitive revocation. A definitively revoked certificate is not reinstated, while a suspended certificate needs its own status-change and notification handling. Where possible, the TSP shall inform the subject and, where applicable, the subscriber when a certificate is revoked or suspended.
Where a (CRL) is used for end-user certificates, EN 319 411-1 gives concrete operating checks. A CRL or variant, such as a delta CRL, is published at least every 24 hours until the last CRL has been published. Each CRL states the time of the next scheduled issue. For the last CRL in a certificate scope, nextUpdate is set to 99991231235959Z. The CRL is signed by the CA or an entity designated by the TSP.
A useful CRL evidence file shows the published CRL, publication timestamp, nextUpdate value, signing authority, certificate scope, and any delta or last-CRL handling. It should also show how relying parties find the CRL and how the CA confirms that changed revocation status reached the CRL path within the CPS timing commitment.
This ETSI EN 319 411-1 guide helps align CPS commitments, revocation request handling, CRL publication proof, OCSP responder records, and status-service consistency evidence.
Convert revocation, OCSP, and CRL controls into assigned evidence requests and review-ready records.
Resolve clause, CPS, timing, CRL, OCSP, and status-service consistency questions against cited ETSI sources.
Review missing CPS fields, publication evidence, OCSP responder proof, and CRL consistency gaps before audit handoff.
The general rule requires certificate-status checking services and support for the (OCSP) or CRL, with OCSP recommended. Revocation status information must be available 24 hours per day, seven days per week, protected for integrity and authenticity, include status information at least until the certificate expires, and be publicly and internationally available. A TSP need not provide status services for a certificate carrying the validity assured extension; if that certificate has neither a CRL distribution point nor an OCSP access location, EN 319 411-1 says it should carry the No Revocation Available extensions specified in RFC 9608.
When both CRL and OCSP are used, status updates must become available through all supported methods. The services also must remain consistent over time, while allowing documented differences in update delays. If those delays exist or are possible, the CPS must explain their origin and how relying parties should interpret temporary differences.
Short-term certificates do not all follow one revocation path. EN 319 411-1 allows a TSP not to operate the listed revocation-management controls for short-term end-user certificates where those controls are not applicable. If a can be revoked, the listed request, processing, and revocation duties still apply. If it cannot be revoked, the CPS must identify which certificates cannot be revoked through a service or by the TSP itself.
For non-revocable short-term certificates, the TSP must provide a way to report problems and request information about reported problems, log each notification, and describe that process in the CPS. A good OCSP response or empty CRL may be supplied for compatibility, but the standard warns that checking it adds no validity information. Keep this branch separate from the validity assured extension exception, which concerns whether status services need to be provided.
Review this checklist before an audit handoff or customer evidence request. It is scoped to operational proof for revocation and status services; it does not supersede the full EN 319 411-1 conformity assessment or any external scheme requirement.
"Collection of evidence"
"Certificate revocation and suspension"