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.
PAdES sealing is the single exception: a PDF must be uploaded so the signature can be embedded inside it. CAdES sealing is hash-only — only the SHA-256 digest is sent; the original file never reaches our servers. PAdES requests are processed in-memory and the sealed PDF is streamed back in the HTTP response — Sigill does not write the unsigned input or the sealed PDF to durable storage. What Sigill keeps is the file's hash and a small metadata row; optionally, the RFC 3161 timestamp token and (for CAdES only) the detached .p7s signature, governed by per-tenant settings. PAdES sealed PDFs are never retained.
The Model Context Protocol (MCP) server is a narrow exception inside this exception: because MCP tool responses cannot stream binary content, MCP uploads and sealed downloads transit through temporary slots with a hard one-hour expiry and a 50 MB upload cap, scoped to the originating tenant.
Two classes of request
What goes through sigill.ai
- Timestamp request — hex digest in, RFC 3161 token out
- Timestamp verification — hex digest plus token in, verdict out
- Timestamp inspection — token in, parsed metadata out
- Hash lookup — boolean answer only
- CAdES sealing (
/seal/sign-hash) — SHA-256 digest in, detached.p7sout; original file never leaves the client
The file never reaches our servers. Timestamp verification can also be run entirely offline with openssl ts -verify.
The single exception
- PAdES sealing (
/seal/sign) — PDF bytes in, signed PDF out with the signature embedded - Seal verification — original file plus
.p7sin (CAdES), or sealed PDF in (PAdES), verdict out
PAdES must embed the signature inside the PDF, so the file upload is unavoidable. Both the unsigned input and the sealed output are processed in-memory and streamed back — Sigill does not retain the file bytes.
Independent verification
Every proof returned by sigill.ai is independently verifiable. Timestamps are verified against the TSA that signed the token; electronic seals are verified against the sealing certificate and its issuing CA chain. 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 RFC 3161 timestamps — the eIDAS DSS demo validator resolves the signing certificate against the EU LOTL and produces a qualified verdict for the timestamp. For seals, DSS can classify a seal as AdESeal-QC when the signing certificate is a qualified certificate for electronic seal. A QESeal additionally requires a QSCD and is not currently offered by Sigill.
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.