Quovalis

How qualified status is determined

“Qualified” is not a bit in the certificate. It is the outcome of a procedure — standardised in ETSI TS 119 615 — that resolves the issuing service on the EU trusted lists and evaluates what the matched entry says about certificates like the one presented.

What the certificate claims

A candidate QWAC or QSealC carries the qcStatements extension (ETSI EN 319 412-5): a QcCompliance statement claiming EU qualified status and a QcType naming the certificate type. These are the issuer's claims, written at issuance. Nothing in the certificate can prove them, revoke them when a provider loses its status, or override them when a member state says otherwise — that information lives outside the certificate.

What actually decides

The authoritative source is the issuing service's entry on a national trusted list (reachable via the European Commission's List of Trusted Lists). The procedure, in outline:

  • Chain first. The certificate must chain to a service listed on a trusted list; the matched entry identifies the trust service provider and territory.
  • Service type. Only entries of type CA/QC — CAs issuing qualified certificates — decide qualification (ETSI TS 119 615, clause 4.4). A match against any other service type cannot make a certificate qualified.
  • Service status. The entry's status must be granted; a withdrawn service no longer confers qualified status on the certificates it matches.
  • Qualification overrides. An entry may carry a Qualifications extension (often called Sie, after its XML container) whose criteria select certificates and override what they claim — asserting a certificate is qualified although its statements do not say so, or that it is not, although they do. The overrides win: qualification can be granted or withdrawn purely through this extension.

Because several of these inputs change over time — services are withdrawn, overrides added, lists resigned — the answer is only meaningful relative to a specific trusted-list state. Every validation result pins the exact snapshot it was computed against:

{
  "verdict": "VERDICT_VALID",
  "qualified": {
    "isQualified": true,
    "qcType": "QC_TYPE_WEB",
    "trustServiceProvider": { "name": "Example QTSP", "territory": "NL", "serviceStatus": "granted", … },
    …
  },
  "trustList": {
    "territory": "NL",
    "sequenceNumber": "87",
    "snapshotId": "0198f3a2-7c11-7000-8000-3f9be1a2c002"
  },
  …
}

Scope and honest limits

The mapping evaluates the matched service's current list entry at validation time; service-history entries are not consulted, and the QSCD/SSCD axis of the qualifiers (whether the private key sits in a qualified signature/seal creation device) is not evaluated or reported. Where an applicable override cannot be fully evaluated for the presented certificate, the service does not guess: the certificate is not reported as qualified and the verdict is VERDICT_INDETERMINATE with SUB_INDICATION_QUALIFICATION_UNDETERMINED — unless the certificate already fails on a stronger ground such as revocation or expiry. An indeterminate answer is never silently upgraded to valid.

A qualified result is a technical assessment against the published trust-list data identified in the result document; what it means for a particular regulatory obligation is a question for the relying party (see the Terms for the documented non-claims).

Related