ETSI EN 319 411-2 Identity Proofing

Identity proofing cannot be reviewed in isolation from the certificate policy. EN 319 411-2 uses different qualified certificate policy indicators for natural persons, legal persons, QSCD-backed certificates, and qualified website authentication certificates.

Before reviewing any registration file, identify whether the certificate is issued under QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen. That choice decides whether the evidence must prove a natural person, a legal person and authorized representative, a website-domain link, a QSCD-related route, or a combination of those elements.

For qualified natural-person certificates, EN 319 411-2 requires identity verification by physical presence or by a method that gives equivalent assurance and whose equivalence the TSP can prove. For legal-person certificates, the same structure applies to the authorized representative of the legal person.

Remote or delegated proofing should therefore leave a clear equivalence file. The file should show which route was used, which person or representative was checked, what attributes were validated, and why the route provides assurance comparable to physical presence for the certificate policy in scope.

The identity-proofing outcome has to control certificate issuance, not just sit in a registration archive. EN 319 411-1 requires the TSP to check that certificate requests are accurate, authorized, and complete according to the collected evidence or attestation of identity.

Use a release gate that compares the registration file with the certificate request and the intended certificate profile. The gate should catch mismatches in subject name, organization, role, domain name, representative authority, QSCD indication, subscriber agreement choices, and any attribute that will appear in the certificate.

Identity proofing should produce a replayable registration record. EN 319 411-1 calls for logging registration events and recording the documents or attestations used, unique identification data where applicable, storage location of copies, subscriber agreement choices, the entity accepting the application, validation method, and the receiving TSP or submitting Registration Authority where applicable.

That record should also respect privacy expectations. The standard recognizes that evidence can include personal data such as identity-card or passport information and requires privacy of subject information and protection of registration data confidentiality and integrity.

The most common failures are traceability failures: the certificate profile says one thing, the registration record proves another, or the proofing route is described without evidence that it is appropriate for the profile.

Review these gaps before an audit, conformity assessment, or production certificate issuance run. Each gap should be closed in the registration procedure, CPS, subscriber agreement, certificate request gate, or evidence-retention process.