An RFC 3161 timestamp proves one thing: the digest inside the token existed no later than genTime plus the accuracy field. An upper bound, not a moment. The accuracy field is optional, and three of the six public TSAs I probed omit it entirely. The token carries no requester identity, so it proves neither authorship nor possession.
Ross Jones — Founder, The Hopium Lab. Last modified 22 July 2026.
Every vendor page ranking for this question says a timestamp proves data existed "at a specific point in time." RFC 3161 §2.4.2 defines no such point — it defines a bound, and only in one direction. The anonymous upper bound is the only assertion a plain RFC 3161 token makes: some party held these bytes no later than genTime plus accuracy, and the token says nothing about who.
Why is genTime a bound rather than a moment?
Because the spec defines it that way. RFC 3161 §2.4.2: "By adding the accuracy value to the GeneralizedTime, an upper limit of the time at which the time-stamp token has been created by the TSA can be obtained." Note what gets bounded — the token's creation, not the datum's existence. The digest necessarily existed at or before the TSA built the token, so the sound reading is no later than genTime + accuracy.
Subtraction does not give you the mirror claim: it yields a lower limit on token creation and tells you nothing about how old the datum is. Bytes handed to a TSA today may have existed for a decade. Point-in-time reading — treating genTime as an instant the data came into being — is the failure mode underneath most of the marketing copy on this topic.
Three objects get conflated constantly: the datum, the digest, the token. A TSA never sees the first — RFC 3161 §2.1 requires it "not to examine the imprint being time-stamped in any way (other than to check its length)." The token binds bytes to a clock reading. Everything past that is verifier inference.
A timestamp token is a signed claim by a stranger, about a clock you do not control, over bytes it is forbidden to look at.
What happens when the accuracy field is missing?
You cannot compute the interval from the token; you read a policy document instead. RFC 3161 marks accuracy OPTIONAL and offers a fallback: "When the accuracy optional field is not present, then the accuracy may be available through other means, e.g., the TSAPolicyId."
On 21 July 2026 at 23:13 UTC I sent one identical SHA-256 TimeStampReq — nonce 0x863CA847981426B2 — to six public TSAs and dumped every reply. All six returned Status: Granted to an unauthenticated curl. All six echoed the nonce exactly. Three omitted accuracy.
| TSA | Accuracy in token | Ordering | TSA name in token | TSU cert expires | Signing-cert attribute |
|---|---|---|---|---|---|
| DigiCert | absent | false | absent | 3 Sep 2036 | v1 and v2 |
| Sectigo | absent | false | present | 24 Jun 2037 | v1 only |
| FreeTSA | absent | true | present | 2 Feb 2040 | v1 only |
| Apple | 1 second | false | absent | 17 Aug 2026 | v1 only |
| SSL.com | 1 second | false | absent | 12 Nov 2034 | v2 only |
| SwissSign | 500 ms | false | present | 26 Nov 2027 | v2 only |
Silent accuracy is the failure where a verifier computes an interval from a token with no accuracy field, silently defaulting to zero. For DigiCert and Sectigo tokens the bound lives in a policy PDF keyed by TSAPolicyId. Withdraw or revise that PDF and the interval width of every old token becomes unrecoverable.
Two other columns repay attention. FreeTSA alone sets ordering true, which per §2.4.2 totally orders its own tokens by genTime regardless of accuracy — a relation scoped to that one TSA and worthless across TSAs. And RFC 5816 (March 2010, the only IETF update to RFC 3161) exists so the signing-certificate reference need not be locked to SHA-1; sixteen years on, three of six emit only the v1 attribute and a fourth emits both. Not a break — ESSCertID is a certificate identifier and SHA-1 second-preimage resistance is intact — but a policy demanding no SHA-1 anywhere is met by two of the six.
Can a timestamp be backdated?
Yes, by two different parties, through two unrelated mechanisms. The requester cannot simply ask for a past time — TimeStampReq has no time field at all, which you can confirm in ten seconds with openssl ts -query -text.
What a requester can do is exploit a weak digest. Kelsey and Kohno's chosen-target forced-prefix attack (Herding Hash Functions and the Nostradamus Attack, ePrint 2005/281) commits a hash today and produces a matching document later, at roughly 2^(2n/3) work. Leurent and Peyrin executed a chosen-prefix collision on SHA-1 at about 2^63.4 for a rental cost near US$75,000 in 2020. The TSA is forbidden to look, so the attack is undetectable at issuance. The honest formulation is conditional: backdating is infeasible for the requester so long as the messageImprint hash is collision-resistant. MD5 and SHA-1 are not. The CA/Browser Forum banned SHA-1 timestamp tokens effective 30 April 2022.
A compromised or colluding TSA backdates freely. RFC 3161 §4 names its own mitigations: an audit trail "MAY provide a means to discriminate between genuine and false backdated tokens," and "Two time-stamp tokens from two different TSAs is another way to address this issue."
One scoping caveat. For a plain RFC 3161 token the assertion reduces to trust in one TSA's key and clock. Timestamping in general does not — ISO/IEC 18014-3 and ANSI X9.95 specify linked tokens, and OpenTimestamps anchors a Merkle path into Bitcoin block headers. RFC 3161 simply has no linking construct.
Forward-dating needs no attack at all. DigiCert Europe — a separate qualified service from the timestamp.digicert.com endpoint in the table — states it cleanly in its practice statement: the time in a stamp is "the time of processing by the TSU, not the time of submission nor of acceptance." Hold the data, stamp it whenever. Making something look newer costs patience.
The upper bound is the only sound direction. A token can tell you something is no newer than T. It can never tell you something is no older.
Which TSA should you choose?
Choose on failure behaviour, not latency or price. The discriminating question: what does the service do when its own clock drifts? RFC 3628 §7.3.1 is unambiguous: "If the time-stamp provider's clock is detected as being out of the stated accuracy then time-stamp tokens shall not be issued." Fail closed, or the declared accuracy is decoration.
Five things to read out of a practice statement before wiring anything up. Declared accuracy traceable to UTC — RFC 3628 (November 2003) and ETSI EN 319 421 V1.3.1 (July 2025) both set the baseline at one second or better. Fail-closed behaviour on drift. Audit-trail retention, the RFC 3161 §4 mitigation against a key compromise you will never detect yourself; DigiCert Europe's qualified service keeps eleven years. TSU certificate lifetime no longer than the algorithm stays fit for purpose, per RFC 3628 §7.2.4. And a trust anchor your verifier will actually possess. A token nobody anchors is a signed blob from a stranger.
Apple's design is the outlier: a short-lived RSA-2048 signer expiring 17 August 2026, twenty-seven days after my probe, under a CA expiring April 2027. Sectigo's chain runs to March 2041.
Why do tokens decay, and what stops it?
Tokens decay because the signature that makes them evidence ages out, and RFC 3161 §4 mandates the fix in its own text: "any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date." Read the parenthetical twice: renewal requires the revocation data preserved from the moment of stamping.
RFC 4998 (Evidence Record Syntax, ASN.1, August 2007) and RFC 6283 (XMLERS, July 2011) structure long-term renewal properly, and RFC 4998 §1.2 defines two modes whose costs differ by orders of magnitude. Timestamp renewal triggers on TSU key compromise, or on the timestamp's own signature or hash algorithm weakening: hash the old timestamp, re-stamp, done, originals not required. Hash-tree renewal triggers when the hash algorithm building the trees loses its security properties, and then "all evidence data must be accessed and timestamped" — every archived object, re-read. The asymmetry is the point: key compromise is cheap to survive, hash-function death is not, and hash-function death is unsurvivable once the originals are gone.
Every TSU in the table signs with classical RSA or ECDSA. NIST's draft roadmap IR 8547 — initial public draft, 12 November 2024, still not final — proposes disallowing RSA and ECC in NIST standards after 2035. Sectigo's timestamping CA is valid to 2041. A drafted policy horizon, not a break and not binding, but worth putting in the renewal plan.
Verify-against-today is the implementation bug that ships most often: checking whether the TSA certificate is valid now rather than validating the chain against genTime. Per ETSI EN 319 421 Annex D, verification after certificate expiry still works if the TSU key was not compromised and the hash algorithm, signature algorithm and key size remain supported. Capture the full chain plus CRL or OCSP responses at stamping time.
When does a timestamp add nothing?
When the evidence already exists elsewhere, or when the dispute is about something else entirely. Six cases where a token is cost without benefit.
You already hold an append-only, independently witnessed, published log — a Certificate Transparency log, a git history pushed to a third party. A token adds a second trust assumption and no new evidence; see tamper-evident without blockchain.
Orphaned digest — the preimage is gone. A token over a digest you cannot reproduce the input for is unverifiable, and RFC 4998 hash-tree renewal becomes impossible.
Nobody disputes the date. A timestamp is evidence for an adversarial future.
The dispute is about authorship or possession. Timestamp a signature instead, via the signature-time-stamp attribute id-aa-timeStampToken (OID 1.2.840.113549.1.9.16.2.14, RFC 5126 / ETSI EN 319 122-1), whose messageImprint covers the signature rather than the document. sigstore scopes the claim precisely: the timestamp shows the signature, not the artifact, was created at a certain time.
Sunset token — retention horizon exceeds willingness to run a renewal process.
The verifier will not hold your trust anchor.
One legal correction, one boundary. Under eIDAS Article 41(2) a qualified electronic time stamp enjoys a rebuttable presumption of accuracy — the burden shifts, nothing is proved. Non-qualified stamps get non-discrimination under 41(1) and no more. eIDAS is EU law, and does nothing for a reader in the US or the Gulf.
An expired token whose algorithms have sunset is worse than no token, because it still looks like evidence.
What should you run before you ship?
Run the protocol against your candidate TSA and read the fields, not the datasheet. Every column in the table came from this loop, one run per TSA:
#!/usr/bin/env bash
# rfc3161-probe.sh — v1.0 (22 July 2026) — The Hopium Lab
# Supports a conformity case. Does not confer one. Not legal advice.
#
# The anonymous upper bound is the only assertion a plain RFC 3161 token
# makes: some party held these bytes no later than genTime plus accuracy,
# and the token says nothing about who.
set -euo pipefail
printf 'probe' > probe.txt
openssl ts -query -data probe.txt -sha256 -cert -out req.tsq
# CHECK 1 — no time field exists in a TimeStampReq. You cannot ask for a time.
openssl ts -query -in req.tsq -text
for tsa in \
"digicert=http://timestamp.digicert.com" \
"sectigo=http://timestamp.sectigo.com" \
"swisssign=http://tsa.swisssign.net" \
"freetsa=http://freetsa.org/tsr" \
"apple=http://timestamp.apple.com/ts01" \
"sslcom=http://ts.ssl.com" ; do
name="${tsa%%=*}"; url="${tsa#*=}"
curl -sS --max-time 25 -H "Content-Type: application/timestamp-query" \
--data-binary @req.tsq "$url" -o "$name.tsr"
# CHECK 2 — Accuracy present? If "unspecified", the interval is NOT in the
# token. Resolve it via the TSAPolicyId policy doc (RFC 3161 2.4.2)
# and archive that document alongside the token.
# CHECK 3 — Nonce echoed byte-for-byte? Replay defence only, never identity.
# CHECK 4 — Ordering. True is scoped to one TSA. Never order across TSAs.
openssl ts -reply -in "$name.tsr" -text | \
grep -Ei "Status:|Policy OID|Time stamp|Accuracy|Ordering|Nonce|TSA:"
# CHECK 5 — TSU key algorithm and expiry vs your retention horizon.
# Classical RSA/ECDSA + a 20-year horizon = a renewal plan, now.
openssl ts -reply -in "$name.tsr" -token_out -out "$name.tst"
openssl pkcs7 -inform DER -in "$name.tst" -print_certs -text -noout | \
grep -E "Subject:|Not After|Public-Key:"
done
# CHECK 6 — archive chain + CRL/OCSP captured AT STAMPING TIME. Validate
# against genTime, never against today. Absent this, the token
# silently becomes unverifiable once the TSU certificate expires.
# CHECK 7 — you still hold the preimage. No preimage, no verification,
# and no RFC 4998 hash-tree renewal.
Archiving the chain and the revocation data costs nothing today and is unfixable once the TSU certificate expires. A timestamp proves nothing about anything anyone did. Pair it with a signature and it becomes: this key signed this content, no later than T. Alone it is an anonymous upper bound — genuinely useful, as long as nobody in the room believes it is more.
Related: Merkle domain separation · Article 12 logging · evidence layer
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026. Engineering guidance, not legal advice.