Search every question across sub-FAQs

The CP is the policy layer. It identifies the certificate policy, quality level, profile, applicability, and requirements that apply to a certificate service or certificate community. ETSI EN 319 411-1 notes that a CP can be defined by the TSP, ETSI, a government, customers, or another community, and that it can be standalone or included within practice statements or terms and conditions.

The Certification Practice Statement is the implementation layer. It is owned by the TSP issuing certificates and explains how that TSP operates the service, including the technical, organizational, and procedural practices used to meet the CP. The CPS can point to lower-level operating procedures, but those detailed procedures may remain confidential when they are internal and proprietary.

Start with a traceability map from each applicable CP requirement to the CPS clause, operating record, or confidential procedure that implements it. This is especially important where certificates carry a CP identifier, because relying parties may use that identifier to judge certificate suitability and trustworthiness.

Do not publish sensitive operating details just to prove alignment. ETSI EN 319 411-1 allows low-level operational procedures to remain internal; the public CPS can be limited to information useful for subscribers, subjects, and relying parties, with confidential evidence available for process review.

Update the CP when the policy itself changes: certificate applicability, certificate profile requirements, assurance level, adopted ETSI policy basis, or the community rules that subscribers and relying parties rely on. EN 319 411-1 says the policy identifier should change when a CP change affects applicability; it does not say that every editorial CP revision requires a new OID. Update the CPS when the TSP changes how it implements the policy, such as identity validation processes, revocation handling, repository availability, RA arrangements, CA key controls, or supporting organizations.

ETSI EN 319 401 also expects a management body to approve the practice statement, responsibilities for maintaining it to be defined, and revised practice statements to be made available after approval. If a CPS change may affect acceptance of the service by subjects, subscribers, or relying parties, notice is part of the governance work.

Treat re-key as a certificate lifecycle event that starts with a new subject public key. A certificate renewal instead keeps the previously certified public key and is allowed only when that key remains cryptographically sufficient for the new validity period and there is no indication of compromise or revocation for another security breach. ETSI EN 319 411-1 clause 6.3.7 says the general certificate application and application-processing requirements in clauses 6.3.1 and 6.3.2 still apply to re-key. The request must remain linked to registration, authorization, current identity or attribute evidence, and the public key being certified. If the CA did not generate the new key pair, the request process must provide reasonable assurance that the subject possesses or controls the corresponding private key.

The CP/CPS should be the operating boundary. It needs to state whether, and under which circumstances, the TSP allows certificate re-key to change the expiry date or certified attributes. If the previous certificate is used to authenticate the re-key request, the TSP checks that the previous certificate exists and is valid.

The evidence should prove why the re-key was allowed and how the new certificate was bound to the right subject. At minimum, keep the re-key request, request authentication result, registration or attribute evidence reused or refreshed, subscriber authorization where the subscriber and subject differ, and the CP/CPS rule that permits any expiry-date or attribute change.

ETSI EN 319 411-1 makes logging specific: registration events include requests for certificate re-key or renewal. Apply retention by record class. Clause 6.4.6 sets at least seven years after the relevant certificate ceases to be valid for CA-managed key-lifecycle logs and the clause 6.3.4 documentation it lists; other re-key records follow the applicable ETSI, disclosed, legal, contractual, and scheme rules.

A subject-certificate re-key can happen before expiry, after expiry, or after revocation. When compromise or another security breach drives the re-key, handle revocation separately from issuance of the new certificate: revocation requests and reports must be authenticated, processed on receipt, and reflected in status information within the maximum delay required by the CPS and ETSI EN 319 411-1. A clean re-key record cannot substitute for evidence that the compromised certificate was revoked.

Do not confuse subject-certificate re-key with CA key changeover. For CA certificate-signing keys, ETSI EN 319 411-1 requires a new CA certificate to be generated and distributed before expiry when the service continues, recommends a suitable interval for affected parties to prepare, and requires a documented CA key-pair generation procedure and ceremony evidence.

Treat suspension as part of the same controlled certificate-status process as revocation, while keeping the two outcomes distinct. A definitive revocation cannot be reinstated under EN 319 411-1; suspension is useful only where the applicable certificate policy, CPS, customer terms, and status systems can represent a temporary invalid state without confusing relying parties.

The CPS must describe whether and for what reasons certificates can be suspended or revoked, who may submit requests or event reports, the request and confirmation process, the status-distribution mechanism, and the maximum delays. EN 319 411-1 sets an outer timing rule: changed status information must be available to all relying parties within 24 hours after receipt of a revocation or suspension request. If a request schedules suspension for a future date, that date may count as the receipt time.

The evidence should show both the decision and the status-system result. A reviewer should be able to see who requested suspension, how the CA authenticated and authorized the source, whether confirmation was required, when the request arrived, what certificate and policy were affected, when the status changed, which CRL or OCSP channel carried the new status, and whether the subject or subscriber was notified.

EN 319 411-1 also requires status information to be available continuously, protected for integrity and authenticity, and available at least until certificate expiry. Where a CA supports both CRL and online certificate status service methods, updates must be available for all methods and the information must stay consistent over time, taking different update delays into account.

A CA should offer suspension only when the surrounding policy, repository, and status-service design can make the temporary state unambiguous. Operational delay and inconsistent treatment both create problems: relying parties, subscribers, auditors, customer contracts, and the CA's status infrastructure need the same interpretation.

Before enabling or continuing suspension, compare the certificate policy, CPS, subscriber agreement, relying-party notice, CRL profile, OCSP behavior, repository wording, and incident or compromise procedures. The documents and systems should tell the same story about when suspension is available, how long it can last, who can request it, and what happens next.

Start with the audit boundary. The evidence file should identify the TSP or CA service being assessed, the applicable certificate policy, the CPS version, the certificate profiles and policy OIDs in use, the assessment period, and whether registration, certificate generation, dissemination, revocation management, revocation status, and subject-device provisioning are in scope.

Then map the file to requirement identifiers and operating records. EN 319 411-1 uses requirement IDs such as REG, GEN, REV, CSS, DIS, SDP, and OVR. Informative Annex B points to the separate ETSI TR 119 411-4 conformity assessment checklist. An auditor should be able to follow each sampled requirement from the CP/CPS commitment to the retained record that proves operation during the assessment period.

The core evidence should prove that the certificate service operated as documented. For registration, keep application and identity-validation records, subscriber-agreement evidence, the accepting entity, validation method, RA handoff, and the location of supporting documents. For certificate lifecycle events, keep certificate requests, accuracy and authorization checks, issuance links to registration, renewal, re-key, modification, and dissemination evidence.

For revocation and status services, retain authenticated revocation requests, event reports, resulting actions, timing evidence, CRL or OCSP publication records, and exception records where confirmation or publication timing could not be met. For CA keys, keep key lifecycle logs and ceremony evidence, including the ceremony requirements and collected evidence for CA key generation or installation.

Package the file so the assessor can sample without reconstructing the service from scratch. Use one index for scope and documents, one matrix for EN 319 411-1 requirement IDs, and separate folders for registration, certificate lifecycle, revocation/status, CA key management, audit logs, records archival, supplier or RA evidence, and corrective actions.

Retention should be explicit by record class. Clause 6.4.6 requires the TSP to retain CA-managed key-lifecycle logs and the documentation identified in clause 6.3.4 for at least seven years after any certificate based on those records ceases to be valid. Do not apply that sentence automatically to every audit artifact: show the ETSI requirement, disclosed terms, legal or scheme rule, archive location, integrity control, and access path that govern each record class.

Treat revocation evidence 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.

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 Certificate Revocation List 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.

Before closing a revocation evidence 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.