Skip to Content
Multi-TSA Configuration

Multi-TSA Configuration

Keel uses RFC 3161  timestamp authorities (TSAs) as external timestamp witnesses for integrity checkpoints and voice session attestations. An RFC3161 timestamp receipt records that a specific hash existed at or before a specific time, signed by an authority outside Keel’s operational boundary.

Keel requests receipts only where timestamping is enabled. Keel requests checkpoint receipts when it publishes a checkpoint, and a receipt witnesses the checkpoint time, so an event is TSA-witnessed only as of the next checkpoint published after it, not at its own time.

Receipts reinforce the governance chain; they do not gate request handling. If one public TSA provider is unavailable, Keel records the failed attempt and keeps the successful receipts instead of implying every witness succeeded.

Current provider ladder

TierProviders Keel requests, where timestamping is enabled
StarterFreeTSA and DigiCert in the plan definition. Starter checkpoint views show status only, with no receipt.
ProductionDigiCert and GlobalSign.
EnterpriseDigiCert and GlobalSign.

FreeTSA, DigiCert, and GlobalSign are external, best-effort witnesses, not Keel-operated, contractual, or SLA-backed timestamp infrastructure. A checkpoint records successful receipts and per-provider attempt statuses; the checkpoint surface shows each plan only the receipts its providers issued. An attempted provider does not imply a receipt.

What is stored

Checkpoint JSON keeps three timestamp fields:

  • tsa - legacy compatibility field containing the first successful RFC3161 timestamp receipt.
  • tsa_receipts - the full list of successful receipt payloads.
  • tsa_attempts - per-provider success or failure records, so partial witness failures are visible.

A Production checkpoint can therefore show one successful receipt and one failed attempt. That is degraded timestamp evidence, not a silent success.

Verification semantics

Keel validates timestamp receipts in two layers:

  1. Message-imprint replay. The receipt’s RFC 3161 MessageImprint must match the checkpoint composite_hash.
  2. OpenSSL-backed authenticity validation. When a TSA CA bundle is configured, Keel validates the CMS signature, configured trust-store chain, and timestamp-signing purpose (timestampsign).

The verifier iterates across tsa_receipts, with legacy tsa fallback for old checkpoints. Public CA-operated providers require no API keys or customer secrets.

Customer-selected timestamp authorities: not available

Customer-selected timestamp authorities are not available on hosted Keel, on any plan. Hosted Keel uses one Keel-wide timestamping configuration; there is no per-customer TSA profile, trust topology, dashboard configuration, or archival/LTV policy management.

Boundaries

Keel does not claim legal or court-grade timestamp guarantees. With --require-tsa-chain, verification checks the verifier release’s bundled CRL snapshot at RFC 3161 genTime; it does not implement live OCSP or CRL fetching, archival/LTV validation, or eIDAS qualified timestamp validation. Keel does not offer a timestamping arrangement that meets those requirements today.

Last updated on Edit this page on GitHub 
Control Framework MappingsRoute Guarantees