Skip to content
Sigilbase

Qualified anchoring#

External anchoring places each sealed checkpoint's hash beyond the operator's reach: after sealing, the hash is timestamped by independent RFC 3161 timestamping authorities, so a rewritten history would contradict tokens that already exist outside Sigilbase. Qualified anchoring is the same mechanism with a stronger authority behind it.

What "qualified" means#

In the EU (and under the parallel UK regime), a qualified trust service provider (QTSP) is a timestamping authority that has been audited against the eIDAS regulation's requirements and appears on a government-maintained trusted list. A timestamp issued by a QTSP's qualified service is a qualified electronic time stamp, and under eIDAS it enjoys a presumption of the accuracy of the time it indicates and of the integrity of the data bound to it.

That presumption attaches to the token itself. It says nothing about the truth of what any event claims — an event recorded falsely is timestamped just as faithfully as a true one. What the qualified timestamp establishes is when the sealed hash existed, on the authority of an independently audited third party.

What changes in Sigilbase#

When an operator configures a qualified provider, each token from it is recorded with the provider's status as configured at anchor time, together with the token signer certificate's subject and serial parsed from the token. Where that anchor is displayed — in the product, in Certificates of Evidence, and in evidence bundles from format 1.3 — the display states the provider's name, its jurisdiction, and its qualified status.

Deployments that want the stronger posture can additionally require it: with the strictness option enabled, a checkpoint only counts as fully anchored once at least one of its tokens came from a qualified provider. Sealing never waits on anchoring either way — a provider outage delays tokens, never evidence.

What deliberately does not change#

The mathematics are identical. A qualified token is parsed, checked, and chain-verified exactly as any other RFC 3161 token, against trust roots configured on the verifying side. The recorded status is metadata about the anchor: it appears in no hash, and the standalone verifier reports it without ever letting it influence a verdict — a token claimed to be qualified that fails its cryptographic checks fails, exactly as any other token does. What being qualified changes is what can honestly be said about the token, not what the token proves.

The honest limits#

This page inherits the verification guarantee's boundaries, stated plainly in How verification works:

What passing verification proves:

  • Integrity. No event in the exported range differs by even one byte from what was sealed. Every fingerprint was recomputed from the raw data and matched.
  • Completeness of the range. Within the exported range no event has been removed, none inserted, and none reordered. The sequence numbers are dense, the chain closes, and every sealed range rebuilds to the same fingerprint that was signed.
  • Continuity. The checkpoints themselves chain together, so a whole sealed period cannot be quietly dropped from the middle.
  • Authenticity. Every seal carries a valid signature from a listed signing key. If you have compared those keys against the ones Sigilbase publishes, the bundle is anchored to Sigilbase's identity, not merely internally consistent.

What it does not prove:

  • It does not prove events were true when written. If a system recorded that a backup succeeded when it did not, Sigilbase seals the false statement faithfully. Tamper-evidence starts at the moment of ingestion, not before.
  • It does not prove the exported range is the whole story. Verification covers the range in the bundle. Whether other relevant streams or periods exist is an audit-scoping question; the stream's checkpoint listing shows the full sealed extent if you need it.
  • It does not cover the gap before sealing. Events are sealed within minutes of arrival. Until an event's checkpoint exists, the cryptographic guarantee has not yet attached to it. The seal's timestamp tells you exactly when rigidity began.
  • It does not identify people. actor is whatever the writing system said it was. Sigilbase proves the record of the claim is unaltered, not that the claim's author was who they said.

How any authority, regulator, or tribunal weighs this evidence is a question for the professionals handling your matter, in their jurisdiction, on their facts. Sigilbase states what the mathematics establish and what a qualified timestamp presumes under eIDAS — nothing further.