ETSI EN 319 411-1 Revocation Evidence Workflow

The first evidence item is the 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 standard requires the time used for revocation services to be synchronized with UTC at least once every 24 hours, and the maximum delay from receiving a revocation or suspension request to making the status change available to relying parties is at most 24 hours. If confirmation cannot be completed within 24 hours, the exception procedure and recorded justification become part of the evidence pack.

The evidence trail is incomplete until relying parties can check certificate status. EN 319 411-1 requires certificate status services, requires revocation status information to be available 24 hours per day and 7 days per week, and requires integrity and authenticity protection for the status information.

If the service uses CRLs, the workflow should prove the CRL publication schedule, nextUpdate handling, signing authority, and any last-CRL condition. If the service uses OCSP, it should prove responder profile handling and that non-issued certificates are not returned as good. If both CRL and OCSP are supported, updates must be available through both methods and the CPS must explain possible delays and how to interpret differences.

Use this table as the operating workflow for each revocation case or periodic audit sample: Step | Owner | Evidence | Acceptance test.

1 | CPS owner | CPS revocation procedure, certificate policy mapping, subscriber and relying-party disclosures | The CPS identifies submitters, submission methods, confirmation rules, revocation and suspension reasons, status mechanisms, and maximum delays.

2 | Revocation officer or authorized operations role | Request record, event report, submitter authentication, certificate serial number, reason, receipt timestamp | The request was processed on receipt and authenticated as coming from an authorized source.

3 | CA or revocation management service | Decision record, approval trail, confirmation result, exception justification if needed | The status-change decision is complete within the EN 319 411-1 timing limit or a documented CPS exception applies.

4 | Repository, CRL, or OCSP owner | CRL publication log, OCSP response evidence, endpoint monitoring, signer controls | Relying parties can obtain protected status information through the required method.

5 | Audit and records owner | Revocation log, resulting action, retained records, change review | Requests, reports, and resulting actions are logged and retained with the relevant certificate lifecycle evidence.

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 requests and reports relating to revocation and the resulting action. It also requires retention of specified lifecycle records for at least seven years after any certificate based on those records ceases to be valid. The retention rule means the revocation workflow should not depend on short-lived ticket comments or monitoring dashboards that cannot be reproduced later.

Short-term certificate handling needs its own evidence because EN 319 411-1 distinguishes short-term certificates that can be revoked from short-term certificates that cannot be revoked through a revocation management service. A generic revocation workflow can mislead relying parties if it implies all certificates in the service are revocable in the same way.

For short-term certificates that cannot be revoked, the CPS should describe which certificates cannot be revoked, how problems with those certificates can be notified, how information on a notification can be requested, and how notified problems are recorded in the audit log.