Skip to content

RFC 3161 timestamp authorities

RFC 3161 defines a standard timestamp protocol and token format. A client sends a message imprint, and a timestamp authority returns a signed token containing the imprint and time under the authority's certificate.

What it does well

  • It has broad interoperability across timestamping clients, PKI tooling, and document or signing workflows.
  • It cleanly separates the content from the message imprint sent to the authority.
  • It is a good fit when a counterparty explicitly requires a standard timestamp token and certificate chain.

Trust, privacy, and operations

The usual model trusts one timestamp authority and its signing key, certificate, clock, and service operations. Some deployments are hosted services; others operate an authority and its PKI themselves. The message imprint avoids sending the content, but request metadata and predictable hashes still have privacy implications.

Availability, certificate lifecycle, time-source controls, audit requirements, and token retention are operator responsibilities. RFC 3161 does not itself provide a witness quorum or public-chain anchor.

Difference from Witness

Witness uses a configured threshold of Ed25519 or BLS12-381 witness signatures and exposes local verification, Merkle proofs, and optional cross- or external anchoring. RFC 3161 generally gives a client one authority's signed token. Witness does not claim RFC 3161 token compatibility merely because both systems timestamp hashes.

When to use RFC 3161 instead

Choose an RFC 3161 authority when standards compatibility, an existing PKI process, or a contractual requirement for a TSA token is the deciding factor and a single-authority trust model is acceptable.