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.
CAdES and JAdES sealing are hash-only — only the SHA-256 digest is sent; the original file never reaches our servers. PAdES sealing has two modes: the delegated SDK mode assembles the signature on the customer's machine and transmits only the ByteRange digest — the PDF never reaches Sigill — while the upload mode (used by the web app) transmits the PDF so the signature can be embedded server-side. Uploaded 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 detached seals only) the detached .p7s (CAdES) or .jades.json (JAdES) 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 / JAdES sealing (
/seal/sign-hash) — SHA-256 digest in, detached.p7s(CAdES) or.jades.json(JAdES) out; 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 upload paths
- PAdES upload sealing (
/seal/sign, used by the web app) — PDF bytes in, signed PDF out with the signature embedded. The delegated SDK mode (/seal/sign-pades-hash) avoids the upload entirely: the signature is assembled on the customer's machine and only the ByteRange digest is transmitted. - Full-file seal verification (
/seal/verify) — original file plus.p7s(CAdES) or.jades.json(JAdES) in, or sealed PDF in (PAdES), verdict out. Hash-based verification (/seal/verify-hash) needs no file for the detached formats.
On the upload paths, both the input and the 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
- JAdES detached signatures — any JAdES/JWS-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, Sigill produces advanced electronic seals (AdES); validators such as DSS may classify a seal more highly when a customer brings a qualified certificate for electronic seal (BYOC) — a path Sigill has not validated end-to-end. A QESeal additionally requires a QSCD and is not offered by Sigill today.
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.