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 should 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, the registration data exchange should be secure and limited to recognized, authenticated registration service providers.

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, the workflow should prove that the complete and accurate certificate is available to the subscriber or subject, that relying-party terms and conditions are available and identifiable for the certificate, and that acceptance is supported by durable, human-readable terms and recorded agreement evidence.

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 file 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. 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.

Status-service evidence should cover both the decision and the public signal. Revocation status information must be available continuously, protected for integrity and authenticity, include status at least until certificate expiry, support OCSP or CRL, and be publicly and internationally available. If both CRL and OCSP are supported, updates should be available for both methods and differences caused by update delays should be explained in the CPS.

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.

For archival, the standard requires retaining named records for at least seven years after any certificate based on those records ceases to be valid. The workflow should therefore capture not only the event result, but also the archive location, retention basis, access control, privacy protection for subject information, and handover treatment under the termination plan.