Build a registration evidence pack that shows how the TSP verified the subscriber, subject, attributes, authorizations, certificate request, and retention trail.
Focused on ETSI EN 319 411-1 clauses for initial identity validation, certificate application, registration logging, archival, and RA handoff evidence.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this workflow when a trust service provider needs a reviewable evidence trail for ETSI EN 319 411-1 identity validation. The page turns the standard's registration requirements into checkpoints for evidence intake, subject-type routing, certificate request approval, RA data exchange, and audit retention.
The first evidence decision is not which document to upload. It is whether the certificate request is for a natural person, a natural person linked to a legal person, a legal person or organizational entity, or a device or system operated by one of those parties. ETSI EN 319 411-1 changes the evidence questions depending on that subject type and the applicable certificate policy.
Create one intake record per certificate request. The record should name the subscriber, the subject, the certificate policy profile, the registration route, the registration officer or RA accepting the application, and whether the subscriber is acting for the subject.
Use a routing table before the RA or CA approves the request. A natural person evidence pack should not be treated like an organization or device evidence pack, and domain or IP verification for web certificates has its own referenced verification methods.
The workflow should capture why each evidence route was selected. That matters when a reviewer asks whether physical presence, equivalent-assurance remote proofing, organizational registration data, legal-person representation, device identifiers, or domain/IP checks were the right evidence class for the certificate.
Identity validation evidence is incomplete until it is linked to the certificate request. ETSI EN 319 411-1 requires the TSP to check that certificate requests are accurate, authorized, and complete against the collected evidence or identity attestation.
The workflow should therefore make the approval reviewer compare the requested subject name, attributes, public key, policy profile, and subscriber authorization with the registration evidence before issuance. If the certificate is issued after an earlier validation, the CP/CPS needs to state how long and under what conditions that validation may still be reused.
The evidence pack should separate the data used for identity proofing from the long-term audit record. ETSI EN 319 411-1 says the TSP does not need to archive every item collected during registration over the long term when a reference to the documentation used is enough for the record and applicable law.
For each registration, keep a structured record that lets an auditor reconstruct what evidence was used, who accepted the application, where supporting files are stored, and how the validation method was applied.
Use the workflow to assign registration evidence owners, close subscriber-subject gaps, and prepare a traceable evidence pack for audit or customer review.
Convert identity validation clauses into accountable tasks, evidence requests, and audit checkpoints.
Use cited ETSI source material to resolve registration, subscriber, RA, and retention questions before implementation.
Review the registration evidence route, CP/CPS assumptions, and audit handoff with Sorena.
Identity validation evidence must remain usable after certificate issuance. ETSI EN 319 411-1 requires archival of defined records for at least seven years after any certificate based on those records ceases to be valid, and termination planning must cover registration information, revocation status information, and event log archives.
Before closing the workflow, verify the retention clock, the practice statement wording, the subscriber-facing disclosure, and the termination-plan handoff for registration records. This prevents a clean validation event from becoming unusable evidence later.
Use this table as the operating sequence for a registration evidence pack.
1 | Intake | Registration officer or RA | Subscriber, subject, certificate policy profile, subject type, and subscriber authorization question | Can this request enter the selected validation route?
2 | Evidence collection | Registration officer or trusted registration service | Direct evidence or authorized attestation, subject attributes, organization or device evidence, domain/IP evidence where applicable | Does the evidence class match the subject type?
3 | Request check | CA or authorized approval role | Certificate request, public key proof where needed, registration record, and CP/CPS reuse limits | Is the request accurate, authorized, complete, and current?
4 | Record creation | Evidence owner | Document references, validation method, accepting entity, subscriber-agreement choices, storage location, and RA/TSP handoff records | Can an auditor reconstruct the validation without hidden context?
5 | Retention and handoff | Compliance or audit owner | Retention clock, practice statement wording, confidentiality controls, and termination-plan coverage | Will the evidence remain available for the required archival period?
"General Policy Requirements for Trust Service Providers"
"Identity validation is part of at least one of processes"