How sigill.ai works

Every design decision in the platform serves two properties: your content never has to reach us, and every proof we produce must verify without us. This page walks through the architecture that delivers both — what actually happens between "here is a hash" and "here is evidence."

The hash boundary

The platform is hash-first: every operation is designed around digests, and timestamping, detached CAdES/JAdES sealing, and delegated SDK PAdES sealing are fully hash-only — the content cannot reach us on those paths.

Timestamping, detached CAdES/JAdES sealing, hash-based verification, and delegated PAdES sealing all work this way. The upload endpoints exist for convenience (the web app, simple integrations) — uploaded bytes are processed in memory and never stored. There is no document storage in the product, so the boundary is not a policy promise; it's the shape of the system.

The signing plane: keys that cannot leave

Seal signatures are made with keys held in AWS KMS hardware-backed key stores. Keys are generated inside KMS, sign inside KMS, and are not exportable — not to you, not to us, not to an attacker with our database. The API sends KMS the digest to sign and assembles the returned signature into the standard CMS/JWS structures (signed attributes, certificate binding, the PAdES/CAdES/JAdES profiles).

Two key types exist per tenant scope: RSA-4096 for classical signatures, and ML-DSA-87 (NIST FIPS 204) for the post-quantum hybrid on detached seals. Certificates are either the platform's (zero setup) or yours — you bring a CA-issued certificate, we generate and guard the key, your organisation's name appears on every seal.

For delegated PAdES, this plane is the only server-side half: the PDF structure work happens in the open-source SDK on your machine; the server contributes exactly what only it can — the KMS signature and the timestamp.

The time plane: independent authorities, dispatched

Sigill is deliberately not the source of time in its own proofs. Timestamps come from external RFC 3161 timestamp authorities, so the time claim is attested by a party independent of both you and us:

• Standard timestamps route through a dispatcher that rotates across multiple commercial TSAs with automatic failover — one authority's outage doesn't take down your pipeline, and no single authority is a trust bottleneck.
• Qualified timestamps route exclusively to eIDAS-qualified providers. The platform continuously syncs the EU List of Trusted Lists (LOTL), so qualification verdicts are established against the official register, not vendor claims — see Qualified timestamps.
• Bring-your-own TSA: tenants can register and verify their own authority endpoints and route stamps through them.

The trust plane: evidence captured at sealing time

A seal that depends on tomorrow's infrastructure is fragile, so the platform captures trust material at sealing time and embeds it in the artifact: the certificate chain is resolved (following AIA), fresh OCSP revocation responses are fetched, and both are written into the seal — the DSS dictionary in a PDF, revocation values in CAdES. An archival timestamp then covers the lot (B-LTA). Long-term validation and the archival timestamp are Business-plan entitlements; below that, seals carry trusted time (B-T). The result is a self-contained evidence package; Evidence that outlives the infrastructure covers the long-term mechanics.

What we store

Operation records in an EU-resident database (AWS eu-north-1, Stockholm): the digest, the timestamp token, labels, certificate references, and audit metadata — written transactionally with the operation itself. Optionally, if your organisation enables it, the detached seal artifacts (never the documents). That's the entire retention story; the Trust Center documents it formally.

The exit: verification without us

Every artifact is an open ETSI/IETF standard — verifiable with OpenSSL, PDF readers, the EU's reference validator, or our free public verifier. The platform's own verifier exists for convenience and richer reporting (chain trust, LOTL qualification checks), not as a dependency. The verification model page states this as a design commitment: if sigill.ai disappeared tomorrow, every proof ever issued would still verify.

The runtime, briefly

Containerised services behind a load balancer and WAF in AWS eu-north-1, PostgreSQL for operation records, infrastructure fully defined as code. Security specifics — authentication, tenant isolation, key management policy, audit logging — live in the security architecture page of the Trust Center.