ETSI EN 319 411-1 Identity Validation

The standard separates certification services into registration, certificate generation, dissemination, revocation management, revocation status, and optional subject device provision. Identity validation belongs first in registration, but EN 319 411-1 also states that it can be part of certificate application, certificate issuance, or subject device provisioning.

The CP and CPS should keep that boundary clear. The certificate policy identifies the policy rules and certificate profile expectations; the certification practice statement explains how the TSP operates the process. For identity validation, the CPS should make it possible to trace each certificate request back to the registration evidence, approvals, RA action, and certificate profile used.

Clause 6.2.2 starts with the same baseline for every route: the TSP verifies the identity of the subscriber and subject, collects and validates direct evidence or an attestation from an appropriate authorized source, and checks that certificate requests are accurate, authorized, and complete against that evidence.

The details then depend on who or what the certificate identifies. A natural-person subject needs identity attributes that distinguish the person. A natural person acting with a legal person needs personal identity, organization identity, affiliation, and approvals. A legal-person subject needs organizational identity evidence. A device or system subject needs the device identifier plus the operator's identity and authorization context.

Identity validation fails if the evidence proves the wrong actor. EN 319 411-1 distinguishes the subscriber that requests or contracts for the certificate from the subject identified in the certificate. When those actors differ, the file needs evidence that the subscriber is authorized to act for the subject.

The same discipline applies to registration authorities. A TSP can use other parties to provide parts of the certification service, but the TSP keeps overall responsibility. When external registration service providers exchange registration data, the exchange must be secure and limited to recognized providers whose identity is authenticated.

Registration evidence is not enough by itself. Before issuing, renewing, re-keying, or modifying a certificate, EN 319 411-1 requires the subscriber to have been registered and the subscriber and subject identity to have been validated. The TSP also has to assess that the subject attributes and other certificate information are correct at issuance time.

The CP or CPS should therefore define how long a certificate may be issued after initial identity validation without repeating validation, and how often or under what conditions prior validation can be reused. If the process used for the original identity proofing is no longer acceptable under the CPS because of security concerns, it should not be relied on for issuance.

The identity validation record should show what was checked, which source or attestation supported it, who approved it, and which certificate request relied on it. EN 319 411-1 does not require every collected document to be archived long term; it allows a record to refer to the documentation used at the time, while still requiring the information necessary to verify identity and attributes, including document reference numbers and limitations on validity.

Public-facing disclosures should not expose sensitive registration data. The standard requires the CPS to be publicly available online, but notes that sensitive aspects do not have to be disclosed. For visitors, procurement teams, and relying parties, the useful public content is the policy route, certificate type, validation procedure, reliance limits, subscriber obligations, certificate status checking expectations, and retention period communicated in terms and conditions or PKI disclosure material.