Evidence that outlives the infrastructure

Evidence has a longer lifespan than the infrastructure that produced it. TSA signing certificates expire after five to ten years. Certificate authorities go out of business. RSA and elliptic-curve cryptography are on a countdown against quantum computing. A proof that verifies today but not in 2040 fails at exactly the moment it matters — which is why long-term verifiability is engineered into the formats, not left to hope. Three mechanisms, layered:

1. Seals that carry their own evidence (B-LTA)

The highest assurance levels embed everything a future verifier needs inside the artifact: the certificate chain, revocation evidence (OCSP) captured at sealing time, and a final archival timestamp covering all of it. That's PAdES B-LTA for PDFs and CAdES X-L for detached seals — the levels regulated archives require, and what sigill.ai produces on the Business plan and above, when the certificate chain supports it (including through delegated, hash-only sealing). Plans below Business seal at the trusted-time level (B-T).

The consequence: verification decades from now needs no OCSP responder answering, no CA still in business, no Sigill — the seal is a self-contained evidence package. See Choosing a seal format for the full level ladder.

2. Renewing the chain: archival restamping

An RFC 3161 token is signed by a TSA certificate that will eventually expire. RFC 3161 §4's answer is the timestamp chain: before the certificate expires, timestamp the existing token with a fresh one:

curl -s -X POST https://api.sigill.ai/tsa/restamp \
  -H "Authorization: Bearer $SIGILL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transactionId":"<id of the stamp to renew>","tsaSlug":"auto"}'

The new token attests that the old one existed while its certificate was still valid — the proof's validity is carried forward, link by link, indefinitely. The original file is not needed for restamping, so archives can renew proofs wholesale without touching content.

Each record's evidence page (Evidence → Details) shows the whole chain on one timeline: every token's validity bar, what covers what, the trust state of each signer chain, and the expiry horizon — the active token's TSA-cert certNotAfter, the one date that decides when action is needed. From there you can restamp in one click, verify the full chain cryptographically (POST /api/transactions/{id}/verify-chain), and download every token as a zip for hand-off to auditors.

Seals get the same treatment. A detached CAdES or JAdES seal's signature timestamp is a token like any other — it can be archival-restamped without touching the sealed artifact. For PAdES B-LTA (uploaded or composed remotely by the SDK), the archival DocTimeStamp is tracked as its own token on the seal's evidence record: since it covers the whole sealed PDF, it governs the archival horizon and is the renewal target, while the signature timestamp underneath shows as protected by it.

Renewal can also be watched rather than remembered: enable expiry reminders on an evidence and Sigill emails the tenant 30–180 days before the horizon. A restamp moves the horizon forward and re-arms the reminder; if a risk is deliberately accepted instead, the acknowledgement is recorded in the audit log and the reminder stays silent until the next threshold crossing.

Verification is watched too, not just renewal. A background sweep re-verifies every active chain daily — token signatures, hash linkage, certificate trust — and each verdict is kept, so every record in the Evidence Store carries a last verified state. Verdicts follow the three-state model of ETSI EN 319 102-1: failed only when something definitively broke (a signature or the hash linkage); insufficient material — say, a token whose TSR was never stored — reads indeterminate, never failed. Chains that fail land in a dedicated work queue, and "Verify all now" re-runs the sweep on demand.

A note on qualified origins: restamps route through the standard TSA pool. That doesn't downgrade anything — the eIDAS-qualified token stays inside the chain, still qualified, still verifiable; the fresh standard token simply proves it existed in time.

3. The quantum horizon: hybrid ML-DSA seals

"Harvest now, decrypt later" applies to signatures too: evidence sealed with classical cryptography today could face an adversary with a quantum computer during its retention period. Detached seals (CAdES and JAdES) support a hybrid: pass pqc=True and the artifact carries an ML-DSA-87 signature (NIST FIPS 204) alongside the classical one — two independent signatures over the same content in one artifact.

p7s = client.seal_cades(document, certificate_id=CERT_ID, pqc=True)

The classical signature remains the legal instrument today; the ML-DSA signature is the insurance for the day that changes. The post-quantum post covers the strategy in depth. (Embedded PDF seals can't carry ML-DSA yet — no ETSI profile exists; give long-lived PDFs a detached hybrid seal alongside.)

An archival policy in four lines

1. Seal at the highest level your format supports (B-LTA / X-L) — on Business and above, the default when chains resolve.
2. Prefer qualified: true for material with legal weight — why.
3. Add pqc: true on detached seals for anything with a 10-year-plus horizon.
4. Restamp tokens before their TSA certificates expire — an annual batch job.

Everything above is open-standard behaviour, so the archive's future custodian can verify — and renew — without us. That's the point.