Verification model
What crosses the network, what stays on your machine, and how anyone can verify a Sigill.ai proof without Sigill.ai in the loop.
Data minimisation by protocol
RFC 3161 §2.4 is explicit: a Timestamp Authority must not examine the imprint being time-stamped in any way other than to check its length. Sigill.ai honours this at every layer. For timestamping and verification, only a SHA hash crosses the network — the file itself never reaches our servers.
File sealing is the single exception. PAdES requires the PDF bytes to embed the signature inside the document, and CAdES requires the file bytes to produce the detached signature. Sealing requests are processed in-memory; we retain the resulting signed artefact and its hash, not the unsigned input.
Two classes of request
What goes through Sigill.ai
- Timestamp request — hex digest in, RFC 3161 token returned by an upstream TSA out
- Timestamp verification — hex digest plus token in, verdict out
- Timestamp inspection — token in, parsed metadata out
- Hash lookup — boolean answer only
The file never reaches our servers. Verification can also be run entirely offline with openssl ts -verify.
The single exception
- File sealing — bytes in; PDFs out with an embedded PAdES signature, non-PDFs out with a detached CAdES
.p7salongside - Seal verification — file plus signature in, verdict out
PAdES embeds the signature into the PDF; CAdES produces a detached signature computed over the file bytes. Either way the bytes are necessary. They are processed in-memory; the file itself is not retained after the request completes.
Independent verification
Every proof returned by Sigill.ai is independently verifiable against the upstream authority that signed it — the TSA for timestamps, the CA chain for seals. The third-party tools we cross-check against, and that any recipient of a Sigill.ai proof can use, include:
- RFC 3161 timestamps —
openssl ts -verify -in token.tsr -data file -CAfile ca-bundle.pem - PAdES-sealed PDFs — Adobe Acrobat Reader displays the signature panel and validates the embedded timestamp natively
- CAdES detached signatures — any CAdES-aware verifier, or the eIDAS DSS demo validator below
- Qualified TSR / qualified seals — the eIDAS DSS demo validator resolves the signing certificate against the EU LOTL and produces a qualified verdict
If a proof returned by Sigill.ai fails to validate in one of these tools and you can reproduce the failure, treat it as a bug and write to security@sigill.ai.
Retention of TSR tokens
Whether Sigill.ai stores the bytes of an issued timestamp token alongside its hash is a per-tenant setting. With token storage enabled, the tenant can re-download the original token from the evidence ledger. With token storage disabled, only the digest, the metadata, and the issuing TSA are retained — the tenant is responsible for archiving the token bytes themselves. The setting is itself audited.