RFC 3161 Timestamps - What Courts Actually Accept as Digital Evidence

What Is RFC 3161?

RFC 3161 is an Internet Engineering Task Force (IETF) standard that defines how a trusted third party - called a Time Stamp Authority (TSA) - can cryptographically certify that a piece of data existed at a specific point in time. Published in 2001 and widely adopted in legal and compliance contexts, it is the backbone of trusted timestamping across industries.

Here is how it works in simple terms: you send a cryptographic hash of your data to a TSA server. The TSA combines your hash with its own authoritative clock, signs the result with its private key, and returns a timestamp token. This token is mathematical proof that your exact data existed at that exact time - and neither you nor anyone else could have forged it, because only the TSA holds the signing key.

Think of it like a notary stamp, but for digital files. The notary (the TSA) is an independent third party whose clock and signature you cannot control or manipulate.

Why Your Computer's Clock Is Not Good Enough

Every file on your computer carries a "created" and "modified" timestamp set by your operating system clock. The problem is that anyone can change their system clock to any date and time they want. On Windows, macOS, and Linux, it takes about five seconds.

This means file timestamps from your local machine have zero evidentiary weight on their own. An opposing party can - and routinely does - argue that you simply backdated your system clock before capturing the screenshot. Courts and arbitration panels are well aware of this vulnerability.

Even timestamps from cloud storage services like Google Drive or Dropbox are not independently verifiable in the way courts require. They prove when a file was uploaded, but not when the content was originally captured. And upload timestamps can be manipulated by creating files offline with a false system clock and syncing them later.

How Snapoena Uses RFC 3161 Timestamps

Snapoena now integrates with FreeTSA, a publicly auditable Time Stamp Authority, to generate RFC 3161 timestamp tokens for every capture. Here is what happens when you capture a URL:

1. Snapoena's server visits the URL and takes a full-page screenshot - completely outside your control
2. A SHA-256 hash is computed from the captured image
3. That hash is sent to FreeTSA's RFC 3161 service, which signs it with its own trusted clock and private key
4. FreeTSA returns a signed timestamp token proving the exact moment the capture was made
5. The token is stored alongside your capture and can be independently verified by anyone - including courts, arbitrators, and opposing counsel

The critical difference is that this timestamp does not come from your machine. It comes from an independent third party whose signing key you never had access to. This is the same standard used in EU electronic signatures (eIDAS), code signing, and enterprise document management systems.

From "Documented Screenshots" to "Verified Evidence"

Snapoena launched with what we call documented screenshots - server-side captures with embedded URLs, timestamps, and SHA-256 hashes. That was a significant step up from bare screenshots because it eliminated browser-side manipulation and created a verifiable fingerprint.

But documented screenshots still relied on Snapoena's own server clock for the timestamp. While far more credible than a user's local clock, it was still a single party attesting to the time.

With RFC 3161 integration, Snapoena captures become verified evidence. The timestamp is now attested by an independent, publicly auditable authority. This is the standard that courts, arbitration panels, and regulatory bodies recognize as trustworthy. It transforms the capture from "we say this is when it happened" to "an independent authority cryptographically certifies when it happened."

Full Page Source Capture - Not Just a Picture

Alongside RFC 3161 timestamps, Snapoena now preserves the full DOM and HTML source code of every captured page. A screenshot is a picture of what the page looked like. The DOM capture is a complete record of what the page actually contained - every element, every link, every hidden tag.

This matters because screenshots can be ambiguous. Text might be cut off, links might not be visible, and dynamic content might not render fully. The HTML source removes that ambiguity. It provides a machine-readable, searchable record of the page content that complements the visual screenshot.

Both the screenshot and the HTML source are hashed and timestamped together, creating a comprehensive evidence package that covers both what a page looked like and what it contained under the hood.

What This Means for Your Cases

Whether you are filing DMCA takedowns, pursuing UDRP domain disputes, sending cease and desist letters, or preparing litigation exhibits, the strength of your evidence determines your outcome. RFC 3161 timestamps and DOM capture move your evidence from "someone says this is what the page showed" to "an independent authority certifies this is what existed at this exact time, with full source code to prove it."