STANDARDS
What an RFC 3161 time-stamp token proves
A time-stamp token is a third party's signed statement that a particular hash was presented to it before a particular moment. The authority never receives the document, is forbidden from inspecting the hash it is given, and attests existence and sequence rather than authorship, accuracy or agreement.
01
One narrow assertion, made by somebody else
RFC 3161 defines the protocol between a requester and a Time Stamp Authority. The abstract states the whole purpose in a sentence: "A time-stamping service supports assertions of proof that a datum existed before a particular time." Everything else in the specification serves that one claim.
The assertion is narrow in a way that matters when a record is challenged. A token says that some hash reached the authority no later than the time in the token, and that the authority signed that pairing. It says nothing about who created the underlying data, whether the contents are accurate, whether anyone agreed to them, or whether the person presenting the hash had any right to it. A time-stamp is evidence of existence and sequence; it is not evidence of assent.
The value of the assertion comes from its independence. The party holding the document does not decide what time appears in the token, which is exactly the property a record cannot supply about itself. OctoDoc, the signing system of record, requests these tokens from an external authority rather than asserting its own clock.
03
The authority learns nothing about the document
Two of the requirements above are a confidentiality design rather than a performance optimisation. The authority receives an imprint — a hash — and is instructed not to examine even that beyond checking its length. It therefore cannot read the agreement, cannot identify the parties, and cannot tell one customer's file from another's.
That is why an external time-stamp can be added to a confidential record without widening who has seen it. The party seeking the token discloses nothing; the party relying on the token later can still check that the hash in it matches the file in front of them.
04
What a token does not establish
- 1Not authorship. A token attests that a hash existed, not who produced the data behind it.
- 2Not assent. Nothing in the token indicates that any party agreed to anything.
- 3Not accuracy. The authority is forbidden from examining the imprint, so it cannot and does not vouch for content.
- 4Not permanence on its own. A token is a signature like any other, and the archival profiles exist precisely because the cryptography beneath one ages.
- 5Not a substitute for the record around it. A token is one input to an evidentiary picture that also includes who acted, when they were shown what, and what they confirmed.
SOURCES
Where each figure came from
1. “A time-stamping service supports assertions of proof that a datum existed before a particular time.”
IETF · https://www.rfc-editor.org/rfc/rfc3161.txt · checked 2026-08-12
2. “not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet).”
IETF · https://www.rfc-editor.org/rfc/rfc3161.txt · checked 2026-08-12
3. “to sign each time-stamp token using a key generated exclusively for this purpose.”
IETF · https://www.rfc-editor.org/rfc/rfc3161.txt · checked 2026-08-12
NEXT
OctoDoc, the signing system of record
Nobody wants to manage signing across several tools. Upload a PDF or Word file, or choose a reusable PDF form; ask cited questions, prepare fields, send it for signatures, and keep the result in one account.
Anyone can check a sealed file with no account.
Fifty sends a calendar month on the paid plan, and every one of them seals.