ETSI EN 319 411-1 requirements map

The first mapping decision is the certificate policy profile. EN 319 411-1 distinguishes requirements that apply to any Certificate Policy (CP), conditional requirements, choice-based requirements, profile-marked requirements for LCP, NCP, NCP+, EVCP, OVCP, IVCP, and DVCP, and [WEB] requirements. Unless stated otherwise, NCP+ and EVCP inherit NCP requirements, while DVCP, OVCP, and IVCP inherit LCP requirements. A register that ignores those markings will overstate some duties and miss others.

For TLS/SSL website certificates, keep a separate bridge for CA/Browser Forum dependencies. EN 319 411-1 includes DVCP, OVCP, IVCP, and EVCP profiles that build on ETSI policies and refer to BRG or EVCG requirements. The ETSI map should identify those dependencies without pretending to restate the current CA/B Forum text.

Use the full policy name in the requirements register: Lightweight Certificate Policy (LCP), Normalized Certificate Policy (NCP), Extended Normalized Certificate Policy (NCP+), Domain Validation Certificate Policy (DVCP), Organizational Validation Certificate Policy (OVCP), Individual Validation Certificate Policy (IVCP), or Extended Validation Certificate Policy (EVCP).

EN 319 411-1 uses the CP/CPS split as the backbone of the certificate-service requirements map. The CP says what rule set and certificate quality apply; the Certification Practice Statement (CPS) says how the TSP operates the service to meet that policy. The requirements file should therefore link each operational control back to the CP and CPS clause that makes it auditable.

The CPS map should cover signature algorithms and parameters, certificate profiles, public online CPS disclosure, sensitive-information exclusions, and any BRG or EVCG monitoring obligations for public TLS/SSL profiles. Internal runbooks can support the CPS, but the public artifact should not expose private procedure names or confidential operational details.

Clause 4.3 classifies certification services into registration, certificate generation, dissemination, revocation management, revocation status, and optional subject device provisioning. Use those components as the first column of the requirements map, then attach the applicable clause 5, clause 6, and clause 7 rows.

The map should make subscriber and subject evidence explicit. EN 319 411-1 requires terms and conditions before the contractual relationship, durable human-readable communication, recorded acceptance, and traceable ratification where the subscriber and subject relationship requires it. Clause 6.4.6 requires the clause 6.3.4 subscriber documentation and CA-managed key-lifecycle logs to be kept for at least seven years after the affected certificate ceases to be valid; other records need their own applicable and disclosed retention rule.

CA key-management rows need more than a policy citation. EN 319 411-1 requires secure generation of CA keys, including keys used by revocation and registration services; physically secured environments; trusted-role participation; at least dual control for certificate-signing key creation; ceremony procedures; and a report proving the ceremony followed the stated procedure.

The same map should cover secure cryptographic devices, key backup and recovery, device certification or equivalent assurance, lifecycle end, and activation data controls. For subject keys generated by the CA, add rows for algorithm fitness, secure storage before delivery, protected delivery, deletion after delivery where required, and revocation if unauthorized disclosure is discovered.

If a TSP defines a CP other than the clause 5 policies, clause 7 changes the requirements map. The CP must identify the EN 319 411-1 policy it adopts as a basis, state variances, and have an approving authority such as a policy management authority. A risk assessment should evaluate the requirements for the stated community and applicability, and a defined review process should ensure that the CP is supported by the CA's CPS.

Disclosure belongs in the same map. Informative Annex A's model PKI disclosure statement does not supersede the CP or CPS or create additional normative requirements. It illustrates what relying parties and subscribers may need in plain language: TSP contact information, certificate type and validation procedures, usage limits, subscriber obligations, status-checking obligations, liability limits, applicable agreements, and audit or trust-list references where applicable.