Skip to Content
Timestamp Authority Scope

Timestamp Authority Scope

Keel uses RFC 3161 timestamp-authority (TSA) receipts as external timestamp witnesses for integrity checkpoints. A TSA receipt is a third-party witness that a specific hash existed at or before a specific time. The receipt is signed by an authority outside Keel’s operational boundary, so the timing claim does not depend only on trusting Keel.

This page scopes what the TSA receipt covers, what it does not, and why the architecture is shaped that way. The goal is to give security and compliance reviewers enough precision to write defensible findings without overclaiming.

Current tier ladder

  • Starter: one FreeTSA-backed external timestamp witness, with replayable message-imprint verification.
  • Production: dual independent public CA-operated timestamp witness attempts through DigiCert and GlobalSign, with partial witness failures recorded.
  • Enterprise: Production witnesses plus eligibility for a customer-selected TSA and customer-directed trust topology. Self-serve customer-managed TSA profile storage and configuration UX are not shipped yet.

Public CA-operated timestamp authorities are external, best-effort witnesses. They are not Keel-operated infrastructure and are not described as contractual, SLA-backed, or legally guaranteed services.

Verification path

Keel validates TSA receipts in two layers:

  1. Replayable message-imprint verification. 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 invokes OpenSSL to validate the CMS signature, the configured trust-store chain, and the timestamp-signing certificate purpose (timestampsign).

This does not perform OCSP/CRL historical revocation validation, archival/LTV validation, or legal/court-grade admissibility analysis.

1. What the TSA receipt covers

A TSA receipt issued by Keel covers the composite_hash of an integrity checkpoint, and only the composite hash.

The composite hash is a deterministic function over (scope, sequence_number, last_record_hash) for every chain scope at the moment the checkpoint is published. Concretely:

  • For each project’s hash chain, the checkpoint records the most recent sequence_number and last_record_hash.
  • These per-scope chain heads are concatenated in a fixed order and hashed.
  • The resulting composite_hash is the input to the TSA MessageImprint.

Because the chain itself is tamper-evident — modifying any past event invalidates the chain head’s record_hash — a TSA receipt over the composite hash transitively witnesses that every governance event committed up to that checkpoint existed by the receipt’s timestamp. Backdating an event after a checkpoint witnesses it would require simultaneously rewriting the chain, which the verifier detects, and producing a valid timestamp receipt for the earlier checkpoint hash and time.

2. What the TSA receipt does NOT cover

Three things are routinely assumed to be TSA-witnessed but are not. These are honest non-claims.

2.1 The signed compliance export itself

A signed export bundle carries an Ed25519 signature over its content_hash, produced by Keel’s export_signing key. That signature attests that the export bytes existed at the moment the export was signed, but it is not independently timestamped. The TSA receipt witnesses the chain checkpoint, not the export.

This matters because:

  • The export’s signed_at field is Keel-clock-attested, not TSA-attested.
  • An auditor who needs an independently-witnessed timestamp on the export itself should anchor the export indirectly: confirm that the most recent chain entry referenced in the export precedes a TSA-witnessed checkpoint they trust.

2.2 Individual closure records

Permit closure records (closure_v1 and closure_v2) are signed with Keel’s permit_binding_signing key. The signature proves the closure record was sealed by that key, but the closure_signed_at timestamp is a Keel-clock value, not a TSA-witnessed one.

A closure record’s timing is anchored only to the extent that the chain entry carrying its permit.closed event is included in a subsequent checkpoint covered by a TSA receipt.

2.3 Real-time delivery

TSA receipts are issued at checkpoint cron, on a fixed cadence (typically every five minutes; deployment-configurable). A governance event that fires at second 0 of a five-minute window is not TSA-witnessed until second 300 at the earliest.

For audit purposes this gap is normally irrelevant because evidence is reviewed days or months later. For real-time use cases (live arbitration, in-flight incident response), the TSA receipt is not the right primitive — the chain itself is what’s available immediately.

3. Why the architecture is shaped this way

The TSA-on-checkpoint architecture is deliberate. Two reasons.

3.1 Cost and rate

RFC 3161 calls cost per request. Free TSAs (FreeTSA, etc.) are rate-limited; commercial TSAs (DigiCert, GlobalSign, etc.) charge per timestamp. Issuing one receipt per governance event would scale linearly with platform traffic and make TSA costs proportional to runtime volume.

Issuing one receipt per checkpoint batches the assurance across all events in the checkpoint window. The cost is fixed per checkpoint cycle, not per event. The trade-off is bounded latency before the witness applies.

3.2 The chain does the heavy lifting

A hash chain already provides tamper-evidence within the issuer’s signing-time boundary. The TSA’s job is narrower: prove that the chain’s state existed at a time witnessed by an independent party. Once the composite hash is anchored, the entire chain inherits the witness — modifying any past event invalidates the chain and would require collusion with the TSA to reissue a backdated receipt.

So the TSA does not need to witness every event. It needs to witness the chain head at points along the timeline. Five minutes between checkpoints is an operational choice, not a cryptographic limitation.

4. The signing-time trust boundary (the asymptote)

The verifier proves exported evidence has not been altered after signing. Like any signing system, the trust boundary includes the signer at signing-time.

A compromised writer with access to Keel’s signing keys could, in principle, produce a forged chain entry at the moment of writing, sign a checkpoint over that forged state, and obtain a TSA receipt witnessing the forgery. The TSA does not defend against signing-time compromise; it defends against post-signing tampering.

Defending against signing-time compromise requires a higher-assurance signing architecture (TEE-backed, HSM-backed, hardware-rooted attestation) which is out of scope for the current verifier and is on the Enterprise roadmap.

This is the asymptote. State it explicitly in audit findings; it is the same boundary every cryptographic logging system has, and CISOs read explicit disclosure as engineering maturity rather than as a gap.

5. Common audit questions

How do I know an event from six months ago wasn’t backdated?

Find the first TSA-witnessed checkpoint after the event’s created_at. Verify the checkpoint’s TSA receipt with keel-verify or openssl ts -verify. If the receipt is valid and the chain walk from the event to that checkpoint passes, the event existed by the receipt’s timestamp.

Can the same key be misused at signing time?

Yes, in principle. See §4.

What happens if one TSA is down when a checkpoint is supposed to be issued?

The checkpoint can proceed with partial timestamp evidence. Keel records per-provider tsa_attempts so reviewers can see which providers returned receipts and which failed. In Production, one public CA-operated timestamp authority can fail while the other still produces a receipt. If no TSA responds, the checkpoint remains a signed checkpoint without an external timestamp receipt.

Is the TSA receipt acceptable for SOC 2?

It can support SOC 2 evidence review, because the receipt is standards-based and independently verifiable. Auditors decide whether that evidence is sufficient for their control objective. For regulated industries with stricter timestamp requirements, Enterprise eligibility for a customer-selected TSA lets the customer direct the trust topology, but customer-managed TSA storage and configuration UX are still a follow-up surface.

Does the TSA witness the export I’m verifying right now?

Not directly. The TSA witnesses the chain checkpoint. Your export is verifiable through the export’s own Ed25519 signature, and the chain entries it carries can be transitively anchored to a TSA-witnessed checkpoint.

Last updated on Edit this page on GitHub 
Trust-Root ChannelsControl Framework Mappings