RFC 3161 Timestamp Inspector — inspecteur d’horodatages RFC 3161

What a time-stamp proves

A time-stamp under RFC 3161 is a signed statement by a time-stamping authority (TSA): "the data with this hash existed at this time". The client hashes its data and sends only the hash in a request (.tsq); the TSA answers with a response (.tsr) that carries a token. The token is a CMS SignedData (RFC 5652) whose content is a TSTInfo structure, signed by the TSA. It proves existence, not authorship: anyone can time-stamp any hash. That is why time-stamps are attached to signatures — in PAdES and CAdES, Authenticode, JAR signing and Sigstore — so that a signature made while its certificate was valid can still be trusted after the certificate expires.

What the inspector reads

The inspector accepts a response, a bare token or a request, as PEM, base64, hex or the binary file, and tells them apart from their structure. From TSTInfo it shows:

• genTime — the time the TSA vouches for, in UTC, and accuracy, the margin it claims (±1s, for example).
• messageImprint — the hash algorithm and the hash of the time-stamped data. This is the link between the token and your data, and the most important field to check.
• policy — the TSA policy OID under which the token was issued, and the serial number, unique per TSA.
• nonce — the random number from the request, echoed so the client can tell a fresh answer from a replayed one.
• ordering and the optional TSA name and extensions.

For a response it also shows the PKI status (granted, granted with modifications, rejection…) and the failure reason of a rejected request.

What it verifies

1. The data. Drop the file that was time-stamped, or paste its digest. The file is hashed in your browser with the algorithm the token names and compared with its message imprint. A token that does not match proves nothing about your file, however valid its signature is.
2. The request. Paste the .tsq you sent: the imprint must match, the nonce must be echoed, and a requested policy must be honoured. If the request asked for the TSA certificate (certReq), the token must include it.
3. The signature. The CMS signature over TSTInfo is verified with the TSA certificate — RSA PKCS #1 v1.5 and PSS, ECDSA and EdDSA are supported — including the content-type and message-digest attributes.
4. The TSA certificate. RFC 3161 §2.3 requires exactly one extended key usage, id-kp-timeStamping, marked critical; the signed attributes must bind the certificate with an ESSCertID or ESSCertIDv2 (RFC 5816). Deviations are reported.
5. Trust. With trust anchors supplied, the chain from the TSA certificate is built and checked at genTime, not today: a token remains valid after its TSA certificate expires, which is the whole point of time-stamping. Intermediates that the token does not carry can be added under Extra certificates.

A token that passes everything but was not compared with data, or whose TSA was not anchored, is reported as intact, not fully verified, and the page says which piece is missing.

What stays in your browser

Everything is computed on this page: the ASN.1 decoding, the hashes and the signature checks. The time-stamped file is read with the File API and only hashed; it is not uploaded and never goes into a share link. A share link carries the token, the request, certificates and a digest — public data — in the URL fragment, which browsers do not send to any server. When you compared a file and it matched, the link carries the token's own imprint in its place.

The inspector does not contact the TSA, fetch certificates over the network or check revocation online; add the certificates you trust yourself. To create a token for testing, OpenSSL is enough:

openssl ts -query -data contract.pdf -sha256 -cert -out contract.tsq
curl -s -H "Content-Type: application/timestamp-query" --data-binary @contract.tsq https://freetsa.org/tsr -o contract.tsr
openssl ts -verify -data contract.pdf -in contract.tsr -CAfile cacert.pem -untrusted tsa.crt

Time-stamps embedded in signed PDFs are checked in place by the PDF signature verifier, which also explains what each PAdES level adds; the article PDF signatures explained goes through a real signing session.