Search every question across sub-FAQs

ETSI EN 319 411-2 makes the EN 319 411-1 revocation request controls applicable to qualified certificate services. In practice, the QTSP's CPS should define who can submit revocation requests or event reports, how they are submitted, when confirmation is required, what reasons can lead to suspension or revocation, and which mechanism distributes revocation status information.

The timing control is concrete: the actual certificate status change must be available to relying parties no later than 24 hours after receipt of the revocation or suspension request. If confirmation cannot be completed within that window, the CPS needs an exception procedure and the QTSP must record the actions taken and justification.

Evidence should show that the QTSP can receive, authenticate, decide, publish, and preserve revocation status consistently for the qualified certificate profiles it issues. The useful audit trail is not a generic owner list; it is the sequence from request or event report through certificate database update and CRL or OCSP publication.

For revoked or suspended certificates, keep enough records to prove the received request time, authorization check, confirmation or exception path, decision time, status publication time, and notification to the subject or subscriber where possible.

Use a checklist that follows the certificate lifecycle clauses rather than a general compliance workflow. The review should prove that revocation requests are controlled, revoked certificates are not reinstated, and relying parties can obtain status information through the published mechanisms.

Start with the certificate policy. ETSI EN 319 411-2 names QCP-n for EU qualified certificates issued to natural persons and QCP-l for EU qualified certificates issued to legal persons. If the private key and related certificate reside on a QSCD, use the matching QSCD policy route: QCP-n-qscd for a natural person and QCP-l-qscd for a legal person.

That distinction also changes the intended certificate use. QCP-n supports advanced electronic signatures based on a qualified certificate, while QCP-l supports advanced electronic seals based on a qualified certificate. The QSCD variants support qualified electronic signatures for natural persons and qualified electronic seals for legal persons.

For a natural-person certificate, keep evidence that the person's identity and any specific attributes were verified either by physical presence or by a method for which the TSP can prove equivalent assurance. EN 319 411-1 adds the practical evidence categories: full name, date and place of birth or another distinguishing identity attribute, and records needed to verify the subject identity and any attribute limitations.

For a legal-person certificate, keep evidence that the legal person's identity and attributes were verified through an authorized representative or an equivalent-assurance method. EN 319 411-1 expects evidence such as the organizational name, relevant registration information where applicable, representation authority, and any association between the legal person and an organizational unit shown in the certificate.

Use the checklist to prevent the common failure mode: issuing or describing a qualified certificate without proving whether the subject route, policy identifier, identity-proofing evidence, and subscriber authority match the actual natural-person, legal-person, or website-authentication scenario.

Start with the relying-party purpose and subject type. EN 319 411-2 defines separate policy identifiers for qualified certificates issued to natural persons, qualified certificates issued to legal persons, qualified certificates tied to a QSCD, and qualified website authentication certificates.

For signatures, the natural-person route is QCP-n, and QCP-n-qscd is used where the private key related to the certified public key resides in a QSCD. For seals, the legal-person route is QCP-l, and QCP-l-qscd is used where the private key resides in a QSCD. For website authentication, EN 319 411-2 separates QEVCP-w, QNCP-w, and QNCP-w-gen depending on the certificate route and the assurance model behind it. QEVCP-w follows EVCG-based requirements, QNCP-w follows BRG-based requirements for natural or legal persons, and QNCP-w-gen is the general-purpose website-authentication route.

If the choice is still unclear, use the subject and assurance model as the tie-breaker: natural person plus signature points to QCP-n or QCP-n-qscd, legal person plus seal points to QCP-l or QCP-l-qscd, legal-person website authentication usually points to QEVCP-w, and natural or legal person website authentication under BRG points to QNCP-w. Use QNCP-w-gen when the website certificate needs the general-purpose route defined in EN 319 411-2 rather than the BRG or EVCG-specific route.

The record should show why the certificate policy and certificate contents match the qualified service being offered. EN 319 411-2 says that including one of its policy identifiers indicates the certificate is issued and managed according to that policy, so the identifier should not be treated as a cosmetic label.

For a QSCD profile, the record needs more than a policy name. It should show why the service uses the -qscd route, how the QSCD condition is reflected in the certificate policy or CPS, and how the certificate contents handle the QSCD statement required for those profiles.

Review the selected profile whenever the certificate purpose, subject population, QSCD handling, website-authentication route, policy OID, CPS wording, or certificate content changes. A profile that was correct for a non-QSCD natural-person certificate may be wrong after a QSCD service launch, and a signature or seal profile does not substitute for a website-authentication profile.

The review should compare the certificate policy, CPS, terms and conditions, certificate profile, and issuance process against the selected EN 319 411-2 policy family before new certificates are issued under the changed route.

ETSI EN 319 411-2 does not treat a trusted list as a loose background reference. In the notice to relying parties, the TSP must explain that, as one condition for relying on the certificate as an EU Qualified Certificate, the validation trust anchor is the service digital identifier in the appropriate EU trusted-list entry for the QTSP.

That means the public reliance message should name the trusted-list dependency clearly. A certificate policy OID, CA certificate, repository page, or marketing statement is not enough by itself if the question is whether the certificate can be relied on as an EU qualified certificate.

The practical evidence set should show that relying parties were told how qualified-certificate reliance depends on the relevant EU trusted-list entry. Keep the public notice text, the CP/CPS or terms section it points to, and a mapping from the certificate service to the trusted-list service digital identifier.

For operational review, retain a dated validation record showing the trusted-list source checked, the QTSP name, the service identifier, the service status considered, the certificate profile or policy OID, and the validation procedure used. This is evidence of the reliance process, not a substitute for the formal trusted list itself.

Use EN 319 411-2 to identify the relying-party notice obligation, then use the trusted-list standards it references for the validation method. ETSI TS 119 612 is referenced for the trusted-list service digital identifier; ETSI TS 119 615 is referenced for procedures for using and interpreting EU Member State national trusted lists.

If the validation question is about whether a signature or seal qualifies, keep that separate from merely checking a certificate. EN 319 411-2 points to ETSI TS 119 172-4 for a signature validation policy that describes validation against EU trusted lists for European qualified electronic signatures or seals.

A QTSP should handle QSCD by first selecting the right ETSI EN 319 411-2 qualified certificate policy. QCP-n-qscd applies to qualified certificates for natural persons where the private key and related certificate reside on a QSCD. QCP-l-qscd applies to qualified certificates for legal persons where the private key and related certificate reside on a QSCD.

The QSCD route brings in the ordinary QCP-n or QCP-l requirements and the NCP+ baseline, then adds QSCD-specific provisions. The standard ties those provisions to subject device provisioning, key pair and certificate usage, key generation and installation, certificate profile statements, and terms and conditions.

When the TSP manages the QSCD for the subject, ETSI EN 319 411-2 restricts use of the private key for signing to the QSCD and distinguishes natural-person sole control from legal-person control. The same area of the standard ties natural-person QSCD keys to electronic signatures and legal-person QSCD keys to electronic seals.

For key generation and installation, the TSP has to verify that the device is certified as a QSCD, ensure the public key to be certified comes from a key pair generated by a QSCD, address third-party managed devices where applicable, and document CPS measures for changes in QSCD status during the certificate validity period.

The main risk is treating QSCD as a marketing or procurement attribute instead of a certificate-policy condition. If the service claims QCP-n-qscd or QCP-l-qscd, the evidence must trace from the policy identifier through device certification, key generation, subject control, certificate profile, CPS text, and revocation or status-change handling.

Another common error is putting the QSCD qcStatement on the wrong certificates. ETSI EN 319 411-2 requires the QSCD qcStatement for QCP-n-qscd and QCP-l-qscd certificates and says it must not be included for certificates that are not issued under those requirements.

No. ETSI EN 319 411-2 expressly warns that conformance to the standard alone does not mean that the TSP or its certificates are qualified. A supervision answer should therefore avoid treating an EN 319 411-2 audit result as a substitute for qualified status.

For a QTSP issuing EU qualified certificates, the standard is still central evidence. It incorporates EN 319 411-1 general policy and security requirements, then adds requirements for EU qualified certificates for signatures, seals, and website authentication.

A useful supervision file should start with the certificate service and policy identifier, then link the CPS, certificate profile, repository, identity proofing, revocation, status service, incident, and termination evidence to the relevant EN 319 411-2 and incorporated EN 319 411-1 requirements.

The file should also prove the relying-party path. EN 319 411-2 says relying-party notices for EU qualified certificates need to explain that the trust anchor is identified in an appropriate EU trusted-list service digital identifier for the QTSP.

The most common mistakes are to blur qualified-status evidence with standards conformance, omit the trusted-list reliance path, or leave the supervision file without a traceable link from the selected certificate policy to the operational records.

Another common problem is treating incident, revocation, and records-retention evidence as optional. EN 319 411-2 and EN 319 411-1 map those topics into the qualified-certificate supervision file, so they need to be present and easy to review.

Start by separating ETSI policy conformance from EU qualification status. EN 319 411-2 says it incorporates the general certificate policy and security requirements from EN 319 411-1 and adds requirements intended to meet eIDAS requirements for TSPs issuing EU qualified certificates, but it also states that conformance to the standard alone does not imply that the TSP or its certificates are qualified under eIDAS.

For each certificate service, identify which EN 319 411-2 policy family is being used: QCP-n for qualified certificates issued to natural persons, QCP-l for legal persons, QCP-n-qscd or QCP-l-qscd when the related private key resides in a QSCD, and QEVCP-w, QNCP-w, or QNCP-w-gen for qualified website authentication certificates. The selected policy drives the certificate-policy statement, CPS controls, certificate profile, subscriber obligations, and evidence set.

The evidence should prove that the certificate was issued and managed under the claimed EN 319 411-2 policy, not merely that the organization has a PKI program. Keep the certificate policy, Certification Practice Statement, terms and conditions, certificate profile, identity-verification record, status-service evidence, and revocation records aligned to the selected QCP route.

For QSCD-backed QCP-n-qscd and QCP-l-qscd certificates, the evidence needs to show the QSCD basis, including the certificate profile treatment of the ETSI EN 319 412-5 QSCD qcStatement and the standard's rule that the QSCD statement is not included in certificates outside those QSCD policies.