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 CPS 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, policy OID, certificate profile requirements, assurance level, adopted ETSI policy basis, or the community rules that subscribers and relying parties rely on. Update the CPS when the CA 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. 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, so the request must remain linked to registration, authorization, identity or attribute evidence, and the public key being certified.

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 also makes logging specific: registration events include requests for certificate re-key or renewal. Records archival then requires retention of relevant lifecycle logs and certificate documentation for at least seven years after any certificate based on those records ceases to be valid.

A subject-certificate re-key can happen before expiry, after expiry, or after revocation. When the re-key is driven by compromise or a security breach, handle the revocation path separately from the replacement-certificate path: 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.

Do not confuse subject-certificate re-key with CA key changeover. For CA certificate-signing keys, ETSI EN 319 411-1 has separate requirements to generate and distribute a new CA certificate before expiry when the service continues, allow affected parties enough interval to prepare, and document the 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 therefore 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 and subscriber-facing terms should describe whether certificates can be suspended or revoked, the reasons and request channels, the mechanism used to distribute status information, and the maximum delays for making the changed status visible to relying parties. EN 319 411-1 sets a hard outer timing rule for revocation or suspension requests: the actual certificate status information must be available to all relying parties within at most 24 hours after receipt of the request.

The evidence should show both the business decision and the status-system result. A reviewer should be able to see who requested suspension, how the CA confirmed the request, 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 expects 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 should be available for all methods and the information should stay consistent over time.

A CA should offer suspension only when the surrounding policy, repository, and status-service design can make the temporary state unambiguous. The risk is not just operational delay; it is that relying parties, subscribers, auditors, or customer contracts may treat a suspended certificate differently from the CA's status infrastructure.

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, and Annex B points to the conformity assessment checklist. An assessor 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 operation of the certificate service, not just document intent. 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. EN 319 411-1 source material identifies a record retention period of at least seven years after any certificate based on those records ceases to be valid, so evidence indexes should show the retention rule, archive location, integrity control, and access path for historical records.

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 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 where both CRL and online status services are supported.

Where CRLs are 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.

Yes, but delegation does not turn registration into an unmanaged hand-off. ETSI EN 319 411-1 defines a Registration Authority as the entity responsible mainly for identifying and authenticating certificate subjects, and notes that an RA can assist with certificate applications, revocation, or both.

For initial identity validation, the TSP must verify the subscriber and subject, collect and validate direct evidence or an attestation from an appropriate and authorized source, and check that certificate requests are accurate, authorized, and complete. The standard also allows evidence of identity to be provided by a subcontracted person, provided that the identity check was performed in line with the clause 6.2.2 requirements.

External registration authorities should be treated as controlled trust-service participants, not just intake vendors. ETSI EN 319 411-1 requires registration data from external registration service providers to be exchanged securely and only with recognized providers whose identity is authenticated.

The same clause points external RAs back to general TSP security requirements, including human resources, operational security, networks, and privacy. ETSI EN 319 401 adds that third-party arrangements need documented agreements and clear obligations for the relevant information security requirements.

The audit file should make the delegated registration chain reconstructable. ETSI EN 319 411-1 requires registration information to be logged and recorded, including document types, unique identification data or references where applicable, storage locations, subscriber-agreement choices, the identity of the entity accepting the application, validation method, and the receiving TSP or submitting RA when applicable.

RA delegation evidence should also cover retention and exit handling. EN 319 411-1 requires specified records to be retained for at least seven years after any certificate based on those records ceases to be valid, and its RA termination clause calls out registration information, revocation status information, and event log archives.

The CA or TSP should start with the terms and conditions that explain certificate use, acceptance, obligations, and limitations. ETSI EN 319 411-1 clause 6.3.4 requires the subscriber to be informed of those terms before the contractual relationship is formed.

The agreement process also needs to be usable as evidence later. The terms must be communicated through a durable means, in human-readable form, before the agreement. Electronic transmission is allowed, but the record must still show what version was presented and how acceptance occurred.

ETSI EN 319 411-1 distinguishes the subscriber from the certificate subject. If the subscriber and subject are separate entities and the subject is a natural or legal person, the agreement is expected to be in two parts: one ratified by the subscriber and one ratified by the subject.

That distinction matters for enterprise and delegated-certificate scenarios. The subscriber part should capture subscriber obligations, any secure-device requirement, consent to registration and revocation records, publication choices, and confirmation that certificate information is correct. The subject part should capture the subject obligations, secure-device acceptance where relevant, and consent to the records kept by the TSP.