ETSI EN 319 411-1 certificate lifecycle workflow

Start the workflow by naming the certificate policy profile, CPS version, certificate profile, registration channel, CA or RA boundary, repository location, revocation-status method, and assessment period. EN 319 411-1 treats registration, generation, dissemination, revocation management, and status services as distinct service components, so the evidence file should not blur those responsibilities.

The intake record should also state whether the subscriber and subject are the same entity, whether the subject is a natural person, legal person, device, or system, and whether the subscriber is authorized to act for the subject. Those choices affect identity validation, agreement records, certificate publication consent, and later revocation or modification handling.

No certificate should enter issuance until the registration file supports the request. EN 319 411-1 expects subscriber and subject identity validation, current assessment of the attributes that will appear in the certificate, an applicable identity-proofing process under the CPS, and proof that the subscriber authorized issuance where the subscriber and subject differ.

If the subject key pair is not generated by the CA, the application process must provide reasonable assurance that the subject has possession or control of the private key associated with the public key presented for certification. When an external registration service provider is used, registration data must be exchanged securely and only with recognized registration service providers whose identity is authenticated.

The issuance gate links the approved registration file to the generated certificate. EN 319 411-1 requires secure certificate issuance to maintain certificate authenticity, measures against forgery, secure handling where the CA generates subject keys, and checks against certificates whose lifetime exceeds the CA signing certificate unless status verification remains possible.

After issuance, prove that the complete and accurate certificate is available to the subscriber or subject and that relying-party terms are available and identifiable for that certificate. Keep two decisions separate: the CPS or terms must say what counts as certificate acceptance, while the subscriber and, where required, the subject must explicitly accept the terms through a traceable act that can later be evidenced.

Renewal, re-key, and modification are separate lifecycle actions. Renewal keeps the subject public key and certificate information unchanged except for the serial number and possible expiry update. Re-key issues a certificate with a new subject public key and may update subject attributes. Modification issues a new certificate because certificate information changes while the key remains the same.

For each change path, the workflow should reopen the relevant application and processing checks instead of copying the previous certificate blindly. The record should show whether prior validation information may still be reused under the CPS, whether certified names or attributes changed, whether terms and conditions changed, and whether the previous certificate was used to authenticate the request.

The revocation branch starts when a revocation or suspension request, problem report, key compromise, certificate-content change, policy non-compliance, or cryptographic weakness affects a non-expired certificate. Where the revocation-management requirements apply, EN 319 411-1 requires authorized and validated revocation handling, timely status changes, and a maximum 24-hour delay between receiving a revocation or suspension request and making the changed status information available to relying parties. The standard has separate branches for short-term certificates that can and cannot be revoked.

Status-service evidence should cover both the decision and the public signal. Unless the certificate contains the validity assured extension, the TSP must provide status checking through OCSP or CRL. Revocation status information must be available 24 hours per day, 7 days per week, protected for integrity and authenticity, cover status at least until certificate expiry, and be publicly and internationally available. If both CRL and OCSP are supported, updates must reach both methods; where update delays can produce temporary differences, the CPS must explain their origin and interpretation.

Close each lifecycle event with an evidence file that can be reconstructed later. EN 319 411-1 calls for logging registration events, certificate generation and dissemination events, certificate lifecycle events, CA-managed key lifecycle events, revocation requests and reports, and subject-device preparation events where NCP+ applies.

Do not apply the seven-year rule to every lifecycle log without checking its basis. Clause 6.4.6 sets that minimum for CA-managed key lifecycle records, including CA-generated subject key pairs, and the documentation identified in clause 6.3.4. Other service records have the retention period stated in the practice statement and notified in the terms and conditions, subject to applicable law, policy, scheme, contract, and termination-plan duties. Record the basis, start and end points, archive location, access controls, subject-information privacy, and handover treatment for each record family.