TSA PP-TSA PUBLIC PROOF TIMESTAMP AUTHORITY
Verifiable digital evidence

Prove that the data existed at that point in time.

PP-TSA issues signed digital timestamps over the hash of a file or record. Your original data never leaves your hands, yet you keep evidence that it existed by the recorded time and that anything presented later is the same data.

TIMESTAMP FLOW Original data stays with you
File or record 01

The original stays in your custody.

Compute the hash 02

Your own system derives a fingerprint locally.

Signed timestamp 03

PP-TSA signs the hash together with the recorded time.

Store and verify 04

Keep the returned token alongside the data and verify whenever needed.

Existence by a time Identity on re-check Signature and chain Public ledger inclusion

Integration: REST API for new in-house implementations, RFC 3161 for PDF, electronic signature and archival tools that already support it. Both are available on the same account.

The original never leaves

Only a hash is sent. PP-TSA cannot see the content, and you keep the data itself.

A time you can present

A signed timestamp ties the fingerprint to a recorded time, so the moment is not just an entry in your own log.

Verifiable long after issue

The signature, the certificate chain and the public ledger entry can be checked again years later.

01 / The problem

Digital data can be replaced without looking any different.

Copying, substituting and overwriting leave almost no trace. When an audit, a dispute or a handover requires an explanation, you need the exact data bound to a time you did not set yourself.

01
File dates prove nothing

Modification dates, screenshots and logs you administer yourself can be changed together with the data they describe.

A time nobody in your organisation can set.
02
"Is this the same file?"

In a dispute or a handover, the question is whether what is presented now is what existed then. Filenames and sizes do not answer it.

Compare fingerprints, not appearances.
03
Evidence has to survive years

A proof that cannot be re-checked after the issuing system changes is not much use when it is finally needed.

Signature, chain and ledger, all re-checkable.
02 / What it proves

What a signed timestamp lets you show

Each row states one claim, and what it does not cover. Click a row to open the detail.

What it establishes

The hash of the data is signed together with the time recorded by PP-TSA. The claim is about existence by that time, not about who authored the content or whether it is correct.

What it prevents

Backdating, and arguments that rest only on file dates or screenshots that the holder could have altered.

What this does and does not establish

A timestamp establishes that the data existed by the recorded time and that what is presented now is the same data. It does not establish who created the content, whether the content is correct, or who holds rights to it. Ledger inclusion may be pending at the moment of issue; pending, overdue and unknown are never reported as complete.

03 / How it works

Sign up and you are issuing

STEP 01
Sign up

Register with an email address and an environment for your organisation is created on the spot.

STEP 02
Choose a plan

Pick one to match your monthly issuing volume. You can change it later.

STEP 03
Take the API key

The key is shown once at issue. Record it the way your organisation handles secrets.

STEP 04
Issue and verify

Hash locally, call over HTTPS, then store the token with the data and verify independently.

REST API
Recommended for new in-house work

Compute the hash in your own system and POST it to /v1/timestamps as JSON. A Base64 token and its metadata come back — suited to backend services, web services and CI pipelines.

RFC 3161
For tools that already support it

Send a TimeStampReq to /tsr and receive a TimeStampResp. Choose this when PDF, electronic signature or archival products already speak RFC 3161.

04 / Who uses it

For any digital record that may need explaining

Not an industry question — it applies wherever "it existed then" or "this is the same file" may have to be shown.

Contracts and invoices

Fix the final version of an agreement, a quotation or an invoice, so a later dispute turns on the data itself rather than on whose copy is newer.

Research and design output

Timestamp results, drawings and design records at the point they are produced, without disclosing their content to anyone.

Software releases

Bind published builds and their manifests to a time, so what shipped can be distinguished from what was rebuilt later.

Audit and inspection records

Keep photographs, measurements and inspection logs verifiable, so authenticity does not depend on the administering system.

05 / Safety

The evidence mechanism itself is designed conservatively

Whether evidence is trusted depends on what is collected and how results are reported. Both are constrained from the start.

Only the hash is accepted

The service takes a fingerprint, an algorithm and request metadata. There is no path by which original content reaches PP-TSA.

Keys are treated as secrets

An API key is shown once at issue and is never displayed again. Lost keys are replaced by issuing a new one and revoking the old.

Results are not rounded off

Signature, certificate chain, timestamp state, ledger inclusion and revocation are reported separately. Pending and unknown are never presented as verified.

Retries never double-issue

Every request carries an idempotency key. A retry after an unclear result reuses the stored request bytes and key rather than issuing again.

06 / FAQ

Frequently asked questions

Fix the moment while the data is still fresh.

COMING SOONComing soon← Packet Pilot Products