Quovalis

Trusted lists and the LOTL

EU trust is not a root store baked into software. It is published data: each member state maintains a signed trusted list of its supervised trust service providers, and the European Commission publishes the List of Trusted Lists (LOTL) that ties them together. Every qualified verdict traces back to an entry in this machinery.

Who publishes what

The chain of custody has three links:

  • The Official Journal of the EU publishes the certificates authorised to sign the LOTL. This is the root of the whole structure — printed law, not a downloadable trust store.
  • The European Commission publishes the LOTL: a signed XML document pointing to every national trusted list — its location and the certificates expected to sign it.
  • Each member state's supervisory body publishes its national trusted list (ETSI TS 119 612): the trust service providers it supervises and, per provider, the individual services — for certificate issuance, entries of type CA/QC, each carrying the CA certificates, a service status and optional qualification overrides.

So the trust data behind a verdict rests on two signature verifications anchored in printed law: the national list is verified against the certificates the LOTL announces for it, and the LOTL against the certificates the Official Journal announces. There is no self-declared trust anywhere in the path.

What a list entry decides

The service entry a certificate chains to is what makes it qualified or not: the entry must be of type CA/QC with status granted, and its Qualifications extension can override what the certificate claims about itself. That evaluation is its own page — how qualified status is determined. This page is about where that data comes from and how it behaves over time.

How Quovalis ingests the lists

An ingestion pipeline runs on a schedule (hourly by default): it fetches the LOTL, verifies its signature against the Official Journal signer certificates, then fetches and signature-verifies every national list the LOTL points to. Each territory's result is stored as an atomic snapshot: either the whole list verifies and parses and becomes the territory's current state, or the previous good snapshot stays active — there is no partially updated territory.

Every validation runs against exactly one coherent snapshot set and records which one, so the result document names the trust state it was computed from:

"trustList": {
  "territory": "NL",
  "sequenceNumber": "87",
  "snapshotId": "0198f3a2-7c11-7000-8000-3f9be1a2c002"
}

The sequenceNumber is the list's own version counter, incremented on every republication (ETSI TS 119 612, clause 5.3.2); the snapshotId identifies our ingested copy. Two validations reporting the same snapshot id were judged against the same ingested copy of that territory's list, byte for byte.

How the lists change

Trusted lists are living documents. Member states republish them routinely — new services granted, old ones withdrawn, certificates rolled, qualification overrides added — and each republication bumps the list's sequence number. Three kinds of change matter to a relying party:

  • A service is withdrawn. The entry does not disappear; its status changes from granted to withdrawn. From the next snapshot on, certificates chaining to it stop being reported qualified — even though the certificates themselves are unchanged and unexpired. This is the clearest reason qualified status must be looked up, not cached forever: verdicts are point-in-time.
  • A territory is de-listed. If the LOTL stops pointing to a territory's list, that territory's anchors are retired and stop backing verdicts. A mere fetch failure never triggers this — only genuine removal from the LOTL.
  • An override changes. A qualification can be granted or withdrawn purely through the list's Qualifications extension, with no change to any certificate.

When a list is unreachable or stale

National list endpoints do go down. A failed fetch of a national list affects only that territory, and the platform keeps serving from the territory's last good snapshot. A failure at the LOTL level is different — it halts the ingestion run for every territory, each of which then serves from its last good snapshot until the LOTL clears. Either way availability degrades gracefully; what the platform never does is pretend the data is fresher than it is. Every list declares when its next update is due, and a snapshot is flagged stale once that moment is more than a bounded tolerance behind — with a hard age ceiling on top, so a list that stops declaring updates is still caught. A verdict that depends on a stale snapshot is VERDICT_INDETERMINATE with SUB_INDICATION_TRUST_LIST_STALE rather than a confident answer computed from data known to be out of date — unless the certificate already fails on a ground staleness cannot repair, such as expiry or revocation.

Inspecting the trust state

The trust state behind your verdicts is not a black box. Two read-only endpoints expose it — GET /v1/trustlist/status reports ingestion health per territory (sequence numbers, snapshot ids, signature checks, next-update times and the stale flag):

curl https://api.quovalis.eu/v1/trustlist/status \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

and GET /v1/trustlist/providers lists the providers and their CA/QC services from the current snapshot, filterable by territory:

curl "https://api.quovalis.eu/v1/trustlist/providers?territory=NL" \
  -H "Authorization: Bearer $QUOVALIS_API_KEY"

Full schemas are in the OpenAPI specification.

Related