Multi-TSA Configuration
Keel uses RFC 3161 timestamp authorities (TSAs) to add an independent third-party witness to integrity checkpoints. A TSA receipt records that a specific hash existed at or before a specific time, signed by an authority outside of Keel’s operational boundary.
This page describes the default TSA configuration shipped today and the forward-looking additive multi-TSA model available to Enterprise customers via early access.
1. What timestamping does in Keel
Keel signs integrity checkpoints with its own key (covered on Verifying Keel Evidence). A TSA receipt adds a second, independent attestation: a third party witnesses that the checkpoint hash existed by the recorded time, without requiring access to Keel’s internal systems to validate that timing claim.
Concretely, every chain anchor (a checkpoint or a signed export) can carry one or more RFC 3161 timestamp receipts in addition to its Keel signature. Receipts are stored alongside the anchor and are verifiable independently with any RFC 3161-compliant tool, including openssl ts -verify.
Receipts are reinforcement, not gating. The governance chain itself does not depend on a TSA being reachable at any given moment.
2. Default configuration (shipped today)
Today, Enterprise plans ship with a single independent RFC 3161 TSA configured as the default witness. The current authority is shared during Enterprise onboarding and security review.
- The default TSA issues standards-compliant RFC 3161 timestamp tokens that are cryptographically equivalent in format to receipts from any other RFC 3161 authority.
- The cryptographic property being asserted — “this hash existed by this time, signed by an authority outside Keel” — is the same regardless of which RFC 3161 authority issues the receipt.
- For most SOC 2 audits, the default RFC 3161 receipt is accepted by auditors as an independent third-party timestamp. For regulated industries with stricter timestamp requirements (FINRA WORM, EU eIDAS qualified, FedRAMP), customers typically prefer a commercially backed TSA — see the multi-TSA early access section below.
This single-TSA configuration is the shipped Enterprise behavior today. The additive multi-TSA model described in the next sections is an early-access enhancement; it is not yet self-serve.
3. Why additive multi-TSA exists
The natural customer instinct, when offered “bring your own TSA,” is to swap the default for a commercial or in-house TSA. Keel’s design rejects swapping in favor of an additive model:
- Adding witnesses never removes existing ones. When an Enterprise customer attaches their own TSA, the default independent witness stays on. Every chain anchor receives receipts from all configured TSAs in parallel.
- Independence is preserved. A customer’s own commercial TSA is, from that customer’s perspective, a vendor relationship they control or can pressure. The default TSA is not. Keeping the default means the independent witness cannot be unplugged — even by the customer themselves.
- Defense in depth. A single TSA outage does not break the evidence chain. Receipts from the remaining responsive TSAs continue to attest to the anchor.
- Stronger collusion resistance. Falsifying a multi-witnessed anchor would require compromising every configured TSA at the moment of stamping, across organizational boundaries.
The positioning principle: adding witnesses never removes existing ones; evidence becomes stronger over time, not dependent on any single vendor remaining in business.
4. Enterprise: Multi-TSA configuration (early access — contact sales)
The configuration shape below is forward-looking and available to design partners only. It is not yet self-serve. To enable multi-TSA on your Enterprise account, contact sales.
When enabled, an Enterprise deployment can configure a list of TSA profiles. Every chain anchor is then timestamped by all configured TSAs in parallel, and all receipts are stored against the anchor.
Planned configuration shape (illustrative):
TSA profiles = [
{ "name": "default", "url": "<default independent TSA>", "role": "independent" },
{ "name": "commercial", "url": "<your commercial TSA>", "role": "commercial" },
{ "name": "internal", "url": "<your in-house TSA>", "role": "operational" }
]The configuration shape above is illustrative and subject to change before GA — the final field names, roles, and validation rules will be confirmed during implementation. Design partners will see the locked shape before it ships.
Properties:
- One row per
(anchor, TSA)is stored. Adding a TSA does not rewrite history — old anchors keep the receipts they were issued at the time. - The TSA’s certificate chain is archived inline at the time the receipt is issued. Verification of a receipt years later does not depend on the TSA’s certificate chain still being publicly retrievable.
- The default independent profile cannot be removed. It is part of the property the tier is paying for.
For backwards compatibility, the existing single-TSA configuration continues to work and is treated as a one-element profile list.
5. Verification semantics (forward-looking)
The standalone verifier CLI today validates a single receipt against a checkpoint hash. Under the multi-TSA model, the CLI grows three explicit modes:
| Mode | Behavior | Use case |
|---|---|---|
any-of-N (default) | A receipt is valid if any non-retired TSA validates | Default — “is this evidence still independently witnessed?” |
all-of-N | All configured TSAs must validate | High-assurance audits — “did every witness attest?” |
M-of-N (threshold) | At least M of N TSAs must validate | Paranoid configurations |
In all modes, the verifier output names which TSAs validated and which did not, so an auditor can make the final judgment. Today, with a single TSA, all modes collapse to the same single-receipt check — the modes become meaningful only once a customer has multiple TSAs configured.
This expanded verifier behavior is part of the multi-TSA early access scope.
6. Failure handling (forward-looking)
TSA failures must never block governance. The chain is the primary evidence; receipts are reinforcement.
Under the multi-TSA model, failure handling is graded:
| TSAs configured | TSAs responding | Action |
|---|---|---|
| N | N | Healthy — all receipts attached |
| N | < N (some failed) | Degraded — anchor proceeds with partial receipts; tsa.degraded event emitted |
| N | 0 | Unavailable — anchor proceeds chain-only; tsa.unavailable event emitted; queued for async retry |
Receipts that succeed on a later retry are recorded as tsa.recovered events and attached to the original anchor. Customers who add or retire TSA profiles see corresponding tsa.profile_added and tsa.profile_retired governance events; retiring a TSA never invalidates receipts that were issued by it before retirement.
The failure events listed here are part of the multi-TSA early access scope.
7. FAQ
Can I disable the default TSA?
No, by design. The independent witness is the property the Enterprise tier is paying for. Customers can add their own TSA(s) alongside the default, but they cannot remove the default — that would silently weaken the evidence posture.
What happens to my receipts if the default TSA goes offline?
Existing receipts remain verifiable as long as the TSA’s certificate chain is preserved. Keel archives the certificate chain inline at receipt time so that historical receipts remain independently verifiable years later, even if the issuing TSA is no longer reachable.
If the default TSA is unreachable when a new anchor is created, the anchor proceeds chain-only, the failure is recorded, and the receipt is retried asynchronously when the TSA recovers. The chain itself is not blocked.
Will the default TSA satisfy my auditor?
For most SOC 2 audits, the default RFC 3161 receipt is acceptable. Auditors evaluate whether timestamps are issued by an independent third party using a standards-compliant protocol — both of which the default TSA satisfies.
For regulated industries — FINRA WORM rules, EU eIDAS qualified timestamps, FedRAMP — auditors typically expect a commercially backed TSA. The multi-TSA early access path is the right surface for those customers: keep the default as the always-on independent witness, and add a commercial TSA alongside it.
Can a TSA receipt be deleted as part of a DSAR or retention request?
No. TSA receipts are governance metadata bound to integrity checkpoints, not user data. They are not subject to user-data deletion requests. See Trust & Integrity for the broader model.
Related pages
- Trust & Integrity — the four-layer integrity model and tier ladder
- Verifying Keel Evidence — how to verify a TSA receipt against a checkpoint hash
- Signed Exports — the export-side counterpart to checkpoint anchoring
- Plans & Entitlements — full plan-by-plan feature ladder