What is RFC 3161 : Explained for Non-Developers

What Is RFC 3161? Trusted Timestamping Explained for Non-Developers

RFC 3161 is an internet standard, published by the IETF in 2001, that defines how to ask a trusted third party to vouch for the time at which a piece of data existed. You don’t send the data itself. You send its cryptographic hash. The third party, called a Time-Stamping Authority (TSA), attaches the current time to that hash and signs the result with its own key. What you get back is a small file, the timestamp token. Anyone can later check it to confirm that the data matching that hash existed no later than the stated time, provided they trust the TSA that signed it.

That is the whole idea. The rest of this article is about why it’s built that way, what the token really contains, and where the approach has limits.

The problem a timestamp has to solve

Computer clocks are easy to change. File “created” and “modified” dates are just text that your operating system fills in, and anyone with a few minutes and an internet search can rewrite them. So if you tell someone “this contract existed on 3 March,” your own computer can’t back that up in any way a stranger should believe.

You need a witness. It has to be someone other than you, and someone the other party has reason to trust. Paper-world solutions were notaries, sealed envelopes mailed to yourself, and bank safe-deposit boxes. RFC 3161 is the digital version of that witness, with the formalities written down precisely enough that software from different vendors can talk to each other.

One timestamp, start to finish

The easiest way to see how it works is to follow a single request. Picture the post-office counter: you hand over a parcel, the clerk stamps a slip with the date and time and signs it, and you walk away with the slip. The twist is that nobody opens the parcel. Here is what happens digitally:

1- Your software turns the file into a hash, a short fingerprint of a few dozen characters that changes completely if even one byte of the file changes. SHA-256 is the usual choice today.

2- It packages that fingerprint into a timestamp request and sends it to the TSA, usually over a normal web connection.

3- The TSA checks its own clock, builds a record containing your fingerprint, the time and a unique serial number, and signs that record with a private key reserved for timestamping.

4- The signed record comes back to you as the timestamp token.

5- You keep the token alongside the original file. Neither is much use without the other.

Later, anyone holding the file and the token can re-hash the file, compare it with the fingerprint inside the token, and check the TSA’s signature. If everything lines up, the file existed, byte for byte, by the time the TSA signed.

Notice what the TSA never receives: your document. The standard was designed around hashes, so confidentiality is built into the protocol rather than bolted on. That said, the TSA still learns that someone asked for a timestamp, when, and from which network address. Fingerprints are private. Requests are not invisible.

What’s inside a timestamp token

You never need to read a token by hand, but knowing what’s in it makes the vocabulary in vendor documents much less intimidating. The core of the token is a structure called TSTInfo, and it carries a handful of fields:

* The message imprint. Your hash, plus a label saying which hash algorithm produced it.

* The generation time. The moment the TSA says it created the token, in UTC.

* A serial number. Unique for each token that TSA issues, which helps with auditing.

* The policy identifier. A reference to the rules the TSA claims to operate under.

* Accuracy. An optional statement of how far the TSA’s clock might be off, down to seconds, milliseconds or microseconds.

* A nonce. An optional random number you put in your request. If it comes back unchanged inside the signed token, you know the reply was made for your request and wasn’t an old one replayed.

The whole record is wrapped in a signature made with the TSA’s key, in a standard envelope format called CMS. The TSA’s certificate has to be marked specifically for timestamping, which stops an ordinary web-server or email certificate from being repurposed to issue tokens. Your request can also ask the TSA to include its certificate in the reply, which makes later verification easier.

One housekeeping detail you may see mentioned: RFC 3161 was updated in 2010 by RFC 5816. The change was narrow. It allowed modern hash algorithms to be used when identifying the TSA’s certificate, and it was motivated by interoperability rather than any newly discovered weakness. Software that says it supports “RFC 3161” generally means the original document with that update in the background.

Trust sits with the TSA, not the math

This is the point that most introductions skip, and it’s the one that matters most when you’re choosing between timestamping methods.

The cryptography in RFC 3161 is sound and well understood. But the time in the token is only as believable as the TSA that wrote it. Verification proves that this TSA signed this fingerprint with this time. It doesn’t, on its own, prove that the TSA’s clock was right, that its key was kept safe, or that its staff never backdated anything. You are trusting an organisation, its audits, and the certificate chain that vouches for it.

For that reason, serious TSAs publish a policy, get audited, and keep their signing keys in hardware security modules. In the EU there’s a formal tier for this, covered below. The practical lesson for non-developers is simple: with RFC 3161, ask who runs the TSA before you ask anything else.

There’s also a time dimension. TSA certificates expire, and cryptographic algorithms age. A token that verifies perfectly today may need extra care in twenty years. The long-term answer is to re-timestamp, wrapping old evidence in fresh timestamps before the old protections weaken. Standards for this exist, including the archive-timestamp profiles in the ETSI signature formats, but it takes active management. A token saved in a folder and forgotten is not a decades-long guarantee.

Where you’ve probably met it already

Even if the term is new to you, RFC 3161 timestamps are already around you:

> Signed software. Code-signing tools commonly add a timestamp so the signature stays valid after the signing certificate expires. The timestamp shows the code was signed while the certificate was still good.

> Signed PDFs. PDF signing workflows can embed a timestamp inside the signature, which is why some signature panels show a “timestamp” line with its own authority name.

> Compliance and archiving systems. Document-management and e-invoicing tools often use a TSA to show a record hasn’t changed since it was filed.

> Qualified electronic timestamps in the EU. More on that next.

RFC 3161, eIDAS and what “qualified” means

In the European Union, electronic timestamps have a legal framework in the eIDAS Regulation (Regulation (EU) No 910/2014, since amended by Regulation (EU) 2024/1183). It draws a line between an ordinary electronic timestamp and a qualified one produced by a qualified trust service provider. In broad terms, a qualified timestamp comes with a legal presumption that its date and time are accurate and that the data it covers is intact. An ordinary timestamp can’t be rejected in court merely because it is electronic or isn’t qualified, but it doesn’t get that presumption. Read the regulation text for the exact wording, because the details matter and national courts apply them.

RFC 3161 enters the picture because the technical standards that sit under qualified timestamps, such as ETSI EN 319 422, build on its protocol and token format. So the relationship is: RFC 3161 is the plumbing, ETSI sets the operating requirements, and eIDAS attaches legal consequences within the EU. An RFC 3161 timestamp from an arbitrary free server is technically the same kind of object as one from a qualified provider, but it doesn’t carry the same legal weight. Outside the EU the picture differs by country, and this article isn’t legal advice for any of them.

What a timestamp can’t tell you

Say the limits out loud and a lot of misunderstandings disappear.

* It doesn’t say who made the file. The token links a fingerprint to a time. Nothing in it identifies an author.

* It doesn’t say the file is original. If someone copies your work and timestamps it, they get a perfectly valid token for it.

* It sets a latest possible date, not a creation date. “Existed no later than” is the correct reading. The file could be much older.

* It doesn’t make a document legally binding. A timestamp is evidence about time and integrity, nothing more.

* It can’t help if the file changes. Change one character and the hash no longer matches. Keep the exact original.

A timestamp is one good piece of evidence in a larger picture. It rarely carries a dispute alone.

Try one yourself (optional)

If you’re comfortable with a command line, OpenSSL can generate a request, and any compliant TSA will answer it. The sketch below uses placeholders, and you’ll need a TSA address from a provider you’ve chosen:

openssl ts -query -data contract.pdf -sha256 -cert -out request.tsq

Post that request file to your TSA’s address, with the content type set to application/timestamp-query, and save the reply as response.tsr. To check it later, you give OpenSSL the original file, the reply, and the TSA’s certificate chain. Everyone else can skip this and simply know that it can be done with ordinary, open tooling, which is a large part of why the standard has lasted.

A different witness: RFC 3161 and blockchain timestamping

Blockchain timestamping answers the same question, “did this exist by that time?”, but replaces the trusted organisation with a public ledger. Certelo works this way. The SHA-256 hash is computed locally on the user’s device, the original file isn’t uploaded to create the record, and the hash is anchored to the Electra Protocol blockchain. Anyone can later check that fingerprint against the public record without asking Certelo’s permission.

The honest comparison is a trade of trust models, not a contest with a winner:

* With RFC 3161, you rely on a named, accountable authority and its certificate chain. That fits regulated settings where a recognised trust service provider is needed, and in the EU a qualified timestamp may carry a legal presumption.

* With blockchain anchoring, you rely on a public ledger whose history is hard to rewrite, and verification doesn’t depend on any one company staying in business. It also doesn’t automatically carry the same formal legal status as an eIDAS qualified timestamp.

A Certelo record is not an RFC 3161 token, and it shouldn’t be described as one. Which is the better fit depends on what you need the evidence for. Teams with strict regulatory requirements sometimes use both. If you want the background on the concept, our guide to trusted timestamping covers it in more depth.

You may ask those:

Does the TSA see my document?

No. The request contains only the hash. The TSA does see the hash, the time of the request and typically your network address.

Is an RFC 3161 timestamp the same as a digital signature?

No. A digital signature ties a document to a key holder. A timestamp ties a fingerprint to a time, and the token itself is signed by the TSA, not by you. The two are often combined, for example when a signed PDF carries a timestamp.

Is an RFC 3161 timestamp legally valid?

It depends on jurisdiction, the type of TSA and the dispute. In the EU, qualified electronic timestamps get a statutory presumption of accuracy and integrity under eIDAS, while other timestamps can still be admitted as evidence. Elsewhere the rules differ, so check with a lawyer where it matters.

Can I verify a token without the TSA’s help?

Mostly yes. You need the original file, the token, and the TSA’s certificate chain, and standard tools such as OpenSSL can do the check. If a certificate was revoked or has expired you may need extra validation data, which is one reason long-term archiving takes planning.

What happens if the TSA shuts down?

Existing tokens can still be verified as long as the certificate chain and validation data are available, which is why people archive them together. Without that data, verification can become hard or impossible.

Is RFC 3161 the same thing as blockchain timestamping?

No. They serve a similar purpose through different trust models, as described above. One relies on a signing authority, the other on a public ledger.

Does an RFC 3161 token prove I created the file?

No. It shows that a specific file fingerprint existed by a specific time. Authorship is a separate question that needs other evidence.