Choosing a seal format: PAdES, CAdES, or JAdES

Every seal sigill.ai produces is an open ETSI/IETF standard artifact — verifiable by third-party tools, forever, with no Sigill dependency. The only decision you need to make is which format fits your content, and the rule is short:

• PDF that humans will open → PAdES (ETSI EN 319 142-1). The seal is embedded in the PDF itself and validates in standard PDF readers. Recipients need nothing from you or from us.
• JSON or JSONL → JAdES (ETSI TS 119 182-1). A detached .jades.json artifact — itself JSON — that travels naturally through APIs, queues, and stores. The right format for API payloads, decision records, and AI/agent evidence.
• Anything else — data, events, exports, archives, binaries: any artifact your system can hash deterministically (or a PDF where you prefer a detached proof) → CAdES (RFC 5126 / CMS). A compact detached .p7s that lives alongside the content.

Detached seals cover exact bytes — by design

JAdES and CAdES seals bind to the exact bytes you sealed. Re-serialize a JSON document — reorder keys, pretty-print it — and the seal no longer matches. This is intentional: evidence is bytes, not semantics. Store the sealed artifact next to the original and treat the pair as immutable.

PAdES is the exception in mechanics only: the seal is written into the PDF as an incremental update, so the sealed PDF is the artifact.

Assurance levels: how much future-proofing is baked in

All formats follow the ETSI ladder. Each level adds evidence so the seal survives longer without depending on anyone still being around:

• B-B — the signature itself, bound to the signing certificate.
• B-T — adds an RFC 3161 timestamp proving when the seal was applied. Every Sigill seal includes this when a timestamp authority is reachable.
• B-LT — embeds the certificate chain and revocation evidence (OCSP), so the seal remains verifiable after the issuing CA's services go offline.
• B-LTA — adds an archival document timestamp over everything above. This is the level regulated archives require for decades-long retention.

PDF seals reach B-LTA on the Business plan and above (lower tiers stop at B-T). CAdES reaches the equivalent X-L level. JAdES seals ship at B-T with revocation evidence embedded best-effort.

Privacy modes

Every format has a hash-only path — the document itself never has to reach sigill.ai:

• CAdES / JAdES: hash-only is the default. You send a SHA-256 digest to /seal/sign-hash; the detached seal comes back.
• PAdES: use delegated sealing via the SDKs — the PDF signature is assembled on your machine and only the ByteRange digest is transmitted. Upload-based sealing (/seal/sign) remains available for the web app and simple integrations.

In every mode, sigill.ai stores only digests and operation metadata. There is no document storage.

Post-quantum scope

The ML-DSA-87 hybrid (NIST FIPS 204) is available on the detached formats — CAdES and JAdES — as a second, quantum-resistant signature alongside the classical one in the same artifact. It is not available for the seal embedded in a PDF: no ETSI PAdES profile for ML-DSA exists yet, and PDF readers cannot validate it. A PDF that needs quantum-resistant protection today should carry a detached CAdES seal (the PDF is simply the sealed content).

Qualified timestamps

Any seal, any format, can carry an eIDAS-qualified timestamp instead of a standard one — pass qualified: true. Qualified timestamps come from providers on the official EU trust list and carry statutory evidentiary weight across the EU. They draw from a separate quota on paid plans.