ETSI EN 319 411-2 qualified certificate operations

Start each qualified certificate operation with the service boundary: issuing TSP, CA or RA roles, certificate population, subject type, policy identifier, CP, CPS, subscriber terms, repository location, and relying-party notice. EN 319 411-2 incorporates EN 319 411-1 general certificate requirements, so the operating file should show both the general control baseline and the qualified-certificate additions.

The boundary should also separate qualified-service recognition from standards implementation. EN 319 411-2 states that conformance to the standard alone does not make the TSP or its certificates qualified under Regulation (EU) No 910/2014, so keep trusted-list, supervisory, or assessment evidence with the operating record when a qualified-status claim is made.

Qualified certificate operations begin before certificate generation. EN 319 411-2 requires natural-person identity and any certificate attributes to be verified by physical presence or an equivalent-assurance method that the TSP can prove. For legal-person certificates, the identity of the legal person and any attributes are verified through the physical presence of an authorized representative or an equivalent-assurance method.

For qualified website authentication certificates, the identity route depends on whether the subscriber is a natural person or legal person, and the operation must also validate the subscriber's link with the domain name to be certified. Keep this validation evidence with the certificate application, processing, issuance, renewal, re-key, and modification records because later lifecycle actions can depend on what was originally validated.

The issuance operation should prove that the certificate policy identifier in the certificate matches the policy actually applied. EN 319 411-2 lists ETSI policy identifiers for each qualified policy and allows a TSP-allocated OID only when the referenced certificate policy clearly identifies which EN 319 411-2 policy it uses as its basis.

Certificate acceptance and profile checks should be part of the same release gate. If the subscriber agreement is electronic, EN 319 411-2 says it should be signed with an advanced electronic signature or seal. Certificates should include the appropriate qcStatements, and only QCP-n-qscd or QCP-l-qscd certificates should include the QSCD qcStatement.

For QCP-n-qscd and QCP-l-qscd, operational evidence must show more than a policy name. EN 319 411-2 requires the TSP to verify that the device is certified as a QSCD and that the certificate request process ensures the public key to be certified comes from a key pair generated by a QSCD.

Where the TSP manages the QSCD for the subject, the private key must not be used for signing except within a QSCD. Natural-person signature keys are tied to the subject's sole control, while legal-person seal keys are tied to the subject's control. The CPS should also document measures for a QSCD status change before certificate expiry.

Qualified certificate operations need certificate status evidence that remains useful after the certificate validity period. EN 319 411-2 requires revocation status information to be available beyond certificate validity using at least one method used during validity, such as CRL or OCSP, unless the validity-assured short-certificate exception applies.

The CPS and terms should state how status information is made available, including the availability period, CA key compromise handling, and TSP termination handling. Relying-party notices should also explain that the trust anchor for validating the certificate as an EU qualified certificate is the service digital identifier in the appropriate EU trusted-list entry for the qualified TSP.