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
| Tier | Timestamp witness posture |
|---|---|
| Starter | FreeTSA-backed single external RFC3161 timestamp witness. |
| Production | DigiCert and GlobalSign dual independent public CA-operated timestamp witness attempts. |
| Enterprise | Production 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:
- Message-imprint replay. The receipt’s RFC 3161
MessageImprintmust match the checkpointcomposite_hash. - 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.
Related pages
- Timestamp Authority Scope - what RFC 3161 timestamps witness and do not witness
- Verifying Keel Evidence - how to verify TSA receipts, checkpoints, and signed exports
- Trust & Integrity - the layer-by-layer integrity model