Skip to Content
Multi-TSA Configuration

Multi-TSA Configuration

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

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

TierTimestamp witness posture
StarterFreeTSA-backed single external RFC3161 timestamp witness.
ProductionDigiCert and GlobalSign dual independent public CA-operated timestamp witness attempts.
EnterpriseProduction witnesses plus eligibility for a customer-selected TSA and customer-directed trust topology.

DigiCert and GlobalSign are public CA-operated timestamp authorities. They are external, best-effort witnesses, not Keel-operated, contractual, or SLA-backed timestamp infrastructure.


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.


Enterprise customer-selected TSA eligibility

Enterprise is eligible for customer-selected TSA support and a customer-directed trust topology. That means a customer can require a particular trust anchor or TSA relationship as part of an Enterprise deployment plan.

The self-serve management surface is not shipped yet: Keel does not currently provide customer-managed TSA profile storage, dashboard configuration UX, or archival/LTV policy management. Those remain follow-up work.


Boundaries

Keel does not claim legal or court-grade timestamp guarantees. Current verification does not implement OCSP/CRL historical revocation checking, archival/LTV validation, or eIDAS qualified timestamp validation. Customers with those requirements should treat Enterprise customer-selected TSA eligibility as the starting point for a scoped trust-topology review.

Last updated on Edit this page on GitHub