We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 How should certificate authorities handle revocation evidence under ETSI EN 319 411-1

Certificate authorities should be able to prove how revocation requests are received, authenticated, decided, published, and archived for each certificate policy they operate.

Based on ETSI EN 319 411-1 revocation and status-service clauses, with EN 319 401 record-retention support.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
3 sections2 primary sources
Overview

Keep as a traceable chain from CPS procedure to request intake, requester authorization, status-change timing, (CRL) or Online Certificate Status Protocol (OCSP) publication, subject or subscriber notice where possible, and protected archive records. This page applies ETSI EN 319 411-1 V1.5.1 (April 2025). EN 319 411-1 supplies a technical baseline; the applicable certificate policy, assessment scheme, contract, browser program, or law can require shorter deadlines, additional reasons, or different status handling.

Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

Revocation evidence workflow for CAs

Treat as operational proof that the CA followed the CPS procedures required by EN 319 411-1. The CPS needs to state who may submit revocation requests or event reports, how requests are submitted, what confirmation is required, when certificates may be revoked or suspended, how status is distributed, and the maximum delays before relying parties can see the changed status.

For each revocation case, preserve enough evidence to show that the request or report was processed on receipt, authenticated, checked as coming from an authorized source, and converted into updated certificate status within the EN 319 411-1 timing rules. The outer limit is 24 hours from receipt until the changed status is available to all relying parties. For a request scheduled for a future date, the standard allows that scheduled date to count as the receipt time.

  • Keep the CPS revocation procedure, submission channels, authorized requester list, confirmation rules, and allowed revocation or suspension reasons together.
  • Record the received request or event report, intake timestamp, authentication check, authorization basis, decision, reason, approver or trusted role, and any subscriber or subject notification attempt.
  • If confirmation cannot be completed within 24 hours, retain the exception procedure used, the actions taken, and the justification recorded for the case.
  • If the service issues short-term certificates that cannot be revoked, keep the CPS statement identifying that population, the problem-notification mechanism, and the required audit-log record instead of manufacturing a revocation record.
Recommended next step

Build a revocation evidence file for ETSI EN 319 411-1

This FAQ helps align CPS procedures, request records, CRL or OCSP publication proof, UTC timing evidence, and archived records before the next conformity review.

Assessment workflow
Map evidence to controls

Convert revocation clauses into evidence requests for CPS, request intake, status services, logging, and archives.

Explore next step
Research workflow
Check the clause fit

Resolve whether a revocation scenario belongs under request authentication, status publication, CRL, OCSP, or records retention.

Explore next step
Talk to Sorena
Review the evidence file

Walk through missing proof, timing gaps, and archive issues before a customer or audit request.

Explore next step
Question 2

What records should support revocation handling?

The evidence set should prove both the case decision and the publication of status information. EN 319 411-1 requires the maximum delay from receipt of a revocation or suspension request to actual status availability for relying parties to be at most 24 hours, and it applies that same maximum to both methods where CRL and an online status service are supported. The CPS may set a shorter limit for particular revocation reasons.

Where a is used, keep proof that a CRL or variant was published at least every 24 hours until the last CRL for the scope, that each CRL carried the next scheduled issue time unless it was the last CRL, and that the CRL was signed by the CA or a TSP-designated entity. Where OCSP is used, keep responder records and consistency evidence when both OCSP and CRL are provided.

  • Preserve CRL publication logs, CRL files or hashes, nextUpdate values, signing key or delegated-signer evidence, and any last-CRL handling for the certificate scope.
  • Preserve OCSP responder logs, status-response samples, non-issued certificate handling evidence, and consistency records when CRL and OCSP timing differs.
  • Preserve UTC clock-synchronization evidence for revocation services and audit logs so request, decision, publication, and notification times can be compared.
  • Separate ordinary revocable certificates from each population that the CPS identifies as non-revocable; the latter require problem-notification and audit-log evidence under clauses 6.3.9-16 to 6.3.9-19.
Question 3

What checklist should teams use before closing a revocation evidence file?

Before closing a file, verify that the file proves the certificate-specific decision, the status-service outcome, and the archive controls. The test is whether an auditor can reconstruct what was requested, who was authorized, what changed, when relying parties could see it, and where the protected records are retained.

  • Match the certificate, policy OID or profile, subscriber or subject record, revocation reason, request source, and authorization evidence.
  • Confirm that a definitive revocation was not later reinstated, and document any suspension path separately from permanent revocation.
  • Confirm that status was made available through the supported method, or methods, within the CPS and EN 319 411-1 timing constraints.
  • Archive the record with confidentiality and integrity protection, retention aligned to disclosed terms and conditions, and enough metadata to support legal evidence or continuity needs.
Primary sources

References and citations

ETSI EN 319 401 V3.2.1 general policy requirements for TSPs
etsi.org4 citations
Referenced sections
  • Primary ETSI source for keeping accessible, protected, confidential, integrity-preserved service records for evidence, continuity, legal proceedings, and disclosed retention.
  • Clause 7.10 supports retaining accessible, confidential, integrity-protected operational records for evidence and service continuity.
  • Clause 7.10 supports protected archives, UTC time records, and retention of records needed to evidence correct service operation.
Show 1 more
  • Clause 7.10 supports confidentiality, integrity, archive completeness, availability for legal evidence, and retention tied to disclosed business practices.
"Collection of evidence"
More quoted passages
"record and keep accessible for an appropriate period of time"
"The precise time of significant TSP's environmental, key management and clock synchronization events shall be recorded"
"Records concerning the operation of services shall be completely and confidentially archived"
ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements
etsi.org4 citations
Referenced sections
  • Primary source for CA revocation procedures, authorized request handling, 24-hour revocation-status availability, CRL and OCSP status-service rules, and revocation lifecycle requirements.
  • Clauses 6.2.4 and 6.3.9 ground the CPS revocation procedure, authorized request checks, 24-hour status availability rule, and certificate revocation duties.
  • Clauses 6.3.9 and 6.3.10 ground CRL publication cadence, CRL signing, certificate status availability, OCSP or CRL support, and consistency across status methods.
Show 1 more
  • Clause 6.3.9 supports timely revocation from authorized and validated requests, mandatory revocation triggers, notice where possible, and the rule that definitively revoked certificates are not reinstated.
"Certificate revocation and suspension"
More quoted passages
"Requests for revocation and reports of events relating to revocation shall be authenticated"
"Revocation status information shall be available 24 hours per day"
"Once a certificate is definitively revoked"

Related guides

CP vs CPS under ETSI EN 319 411-1

Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers.

ETSI EN 319 411-1 certificate re-key FAQ

What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key.

ETSI EN 319 411-1 Certificate Suspension FAQ

How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence.

ETSI EN 319 411-1 Certification Audit Evidence FAQ

How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files.

RA delegation under ETSI EN 319 411-1

How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable.

Subscriber agreements under ETSI EN 319 411-1

How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence.

Show all related guides (22)

Subscriber identity validation under ETSI EN 319 411-1

How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.

EN 319 411-1 vs EN 319 411-2 Certificate Policy

Compare ETSI EN 319 411-1 V1.5.1 with EN 319 411-2 V2.6.1, including policy profiles, inherited controls, QSCD routes, trusted-list status, and evidence boundaries.

ETSI EN 319 411-1 Audit File Evidence

Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival.

ETSI EN 319 411-1 CA Key Management

CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence.

ETSI EN 319 411-1 certificate lifecycle workflow

Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records.

ETSI EN 319 411-1 Compliance Guide

Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence.

ETSI EN 319 411-1 CP and CPS template

Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence.

ETSI EN 319 411-1 FAQ for Certificate Services

Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention.

ETSI EN 319 411-1 Identity Validation

Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records.

ETSI EN 319 411-1 Identity Validation Evidence Workflow

A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls.

ETSI EN 319 411-1 RA Delegation Guide

How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence.

ETSI EN 319 411-1 RA Delegation Review Workflow

Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence.

ETSI EN 319 411-1 requirements map for certificate services

Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence.

ETSI EN 319 411-1 Revocation Evidence Workflow

Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention.

ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations

Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, applicable 24-hour timing, CRL and OCSP controls, exceptions, and audit evidence.

ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements

Compare ETSI EN 319 411-1 V1.5.1 with the CA/Browser Forum TLS Baseline Requirements, including [WEB] controls, DVCP, OVCP, IVCP, CPS duties, and change monitoring.