RFC 3161 时间戳查看器
RFC 3161 时间戳证明某些数据在给定时间已经存在:时间戳机构(TSA)将数据的哈希与时间一起签名。粘贴令牌(.tst)、响应(.tsr)或请求(.tsq),即可查看其中的内容以及它是否有效——用于比对的文件在这里计算哈希,绝不会上传。
令牌、请求和用于比对的文件都在当前浏览器标签页中读取,不会上传任何内容。
加盖时间戳的文件(可选)
将文件拖到此处,或
在浏览器中用令牌指定的算法计算哈希,并与其消息印记比对。文件不会上传,也绝不会写入分享链接。
请求、证书和信任锚(可选)
示例
这些时间戳请求、响应和令牌由本站测试套件中的测试 TSA(tools/timestamp-token-inspector/fixtures)用 `openssl ts`(OpenSSL 3.6.5)生成;其根证书是“ecdsa.com Test Root CA”,需要它的示例会将其作为信任锚加载。
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
- 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.
- The request. Paste the
.tsqyou 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. - The signature. The CMS signature over
TSTInfois 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. - 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. - 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.