ETSI EN 319 411-1 Revocation Evidence Workflow

The first evidence item is the Certification Practice Statement (CPS) section for revocation of end-user and CA certificates. It should identify who can submit a revocation request or report a revocation event, how the request is submitted, when confirmation is required, the reasons a certificate can be suspended or revoked, the status-distribution mechanism, and the maximum publication delays.

Treat that CPS section as the control map for operations. Each intake channel, authorization rule, confirmation step, suspension reason, revocation reason, CRL location, OCSP endpoint, and relying-party disclosure should be traceable to a clause, an owner, and a record.

The operational workflow should begin when a request or report is received, not when a weekly review queue is opened. EN 319 411-1 says revocation requests and event reports are processed on receipt and authenticated as coming from an authorized source.

The workflow also needs time evidence. The time used for revocation services must be synchronized with UTC at least once every 24 hours. The maximum delay from receipt of a revocation or suspension request to the actual status change being available to all relying parties is 24 hours; for a future-dated request, the scheduled date may count as receipt. If confirmation cannot be completed within 24 hours, follow the CPS exception procedure and record the actions and justification.

The evidence trail is incomplete until relying parties can check certificate status, unless a defined exception applies. EN 319 411-1 requires OCSP or CRL, 24-hour-per-day and 7-day-per-week availability, integrity and authenticity protection, coverage at least until certificate expiry, and public international availability. A TSP need not provide status services for a certificate containing the validity assured extension.

If the service uses a Certificate Revocation List (CRL), prove the publication schedule, nextUpdate handling, signing authority, and any last-CRL condition. If the service uses the Online Certificate Status Protocol (OCSP), prove responder profile handling and that a non-issued certificate is not returned as good. If both CRL and OCSP are supported, updates must be available through both methods and the CPS must explain the source and interpretation of possible temporary differences.

For each step, record the responsible owner, evidence, and decision before continuing.

The evidence pack should prove both the individual revocation outcome and the service control. Include the CPS version in force, the certificate profile and serial number, the request and authorization evidence, timing evidence, decision evidence, publication evidence, and the resulting audit log entry.

EN 319 411-1 requires logging all revocation requests and reports and the resulting action. It does not place every revocation record under the clause 6.4.6 seven-year minimum; that minimum covers CA-managed key lifecycle records and clause 6.3.4 agreement documentation. Revocation records still need the precise retention period stated in the practice statement, the applicable period notified in the terms and conditions, and protection and accessibility under EN 319 401. Do not depend on short-lived ticket comments or dashboards that cannot be reproduced for that period.

A short-term certificate has a validity period shorter than the CPS maximum time for processing a revocation request. EN 319 411-1 distinguishes short-term certificates that can be revoked from those that cannot be revoked through a revocation management service. A generic workflow can mislead relying parties if it implies that every certificate profile is revocable in the same way.

For short-term certificates that cannot be revoked, the CPS must identify which certificates cannot be revoked through a service and which cannot be revoked even on the TSP's initiative. It must explain how to notify a problem and request information about it, and the TSP must record notified problems in an audit log. Separately, a certificate with the validity assured extension does not require a status service; if it contains neither a CRL distribution point nor an OCSP access location, EN 319 411-1 recommends the RFC 9608 No Revocation Available extension.