Let's Seal: Free, Open Standard for Cryptographic Document Sealing

Let's Seal offers a free, open standard (SEAL) that lets anyone cryptographically seal any file to prove it has not been altered, existed by a certain time anchored to Bitcoin, and was issued by a verifiable certificate, with hosted, CLI, and self‑hosted options.

SEAL guarantees integrity, time, and issuer identity in a single proof

A SEAL proof establishes three things cryptographically: the file is unaltered (any byte change breaks the signature), it existed by a certain date anchored to Bitcoin via OpenTimestamps, and it was sealed by a specific certificate that can carry a domain name as a machine‑checkable identity when the organisation proves control of that domain.

The seal is native to each file format so verification needs no special tooling

Depending on the file type, Let's Seal embeds the proof in the format’s standard signature container: PDFs receive a PAdES / X.509 signature, images, video and audio get a C2PA (Content Credentials) manifest, XML gets an enveloped W3C XML‑DSig signature, email becomes S/MIME multipart/signed, and any other file receives a detached CAdES / CMS signature over its SHA‑256. Software artifacts and container images are sealed with a signature plus in‑toto / DSSE attestation (SBOM, SLSA provenance). Because the proof rides inside the native format, a sealed PDF remains a normal PDF that opens anywhere, and a sealed image still displays everywhere.

Verification is free, offline, and does not require an account

Anyone can verify a seal at the public portal verify.letsseal.org or offline using standard tools. For PDFs a PAdES validator with the Let's Seal root pinned works, or the reference verifier python spec/verify.py sealed.pdf sealed.pdf.ots. Email and detached seals are checked with openssl smime -verify or openssl cms -verify. Software artifacts are verified by the usual open artifact‑signing tools. Time stamps are validated with ots verify against the Bitcoin chain, and the public transparency log (RFC 6962) can be audited by fetching inclusion proofs at /api/log/proof?sha256=<hex> and checking them against the signed tree head at /api/log/sth. Consistency proofs at /api/log/consistency show the log is append‑only.

The public transparency log provides an impersonation audit trail

Every seal is written to an append‑only Merkle log (RFC 6962) whose root is signed and anchored to Bitcoin. This lets anyone prove a given seal is included in the log (inclusion proof), prove the log has never been rewritten (consistency proof), and audit the whole system without trusting the operator. If a certificate ever sealed something under a name it shouldn’t have, the evidence is permanent and public.

Issuer identity is bound to domain control, not personal identity

A seal always proves which certificate signed it. Organisations can prove control of a domain (via DNS record or a message to a controller address); that domain is then placed in the certificate as a dNSName. Verifiers read the identity straight from the certificate. Organisations that have not verified a domain are shown as self‑asserted self‑asserted. A verified issuer’s badge is the domain it controls, which is globally unique and cannot collide. Abuse can be reported publicly, and an impersonating issuer can be suspended, which stops its keys and drops its verified badge. This mirrors the web’s TLS model: it proves who controls the seal, not a person’s legal identity.

Three ways to use Let's Seal, all free

• Hosted web app at app.letsseal.org – seal files in the browser, send documents for signature, issue branded certificates and credentials.
• Command line and API – the sealbot CLI, a REST API, and SDKs (Python, TypeScript) for integrating sealing into your own systems.
• Self‑hosted – run the full engine under your own certificate authority; the code is identical to the hosted service and carries no host‑only paths.

Self‑hosting follows the same steps as the hosted service

Clone the repository, initialise the certificate authority (./ca/setup-ca.sh init), start the signing service (uvicorn main:app --port 8081 in the signing-service/ directory), and run the web app (npm install, npx prisma migrate deploy, npm run dev). The verification portal is the trust anchor; you can later swap in a paid AATL or eIDAS .p12 with zero code changes if you need a reader’s automatic green check for external verifiers.

Architecture separates issuance, delivery, and verification

The root CA issues an intermediate CA that powers the localhost signing service. The web app anchors each seal to the public ledger, appends it to the transparency log, and publishes proof pages. Verification can be performed by anyone with no Let's Seal server involved.

Community reaction highlights legal trust, environmental, and usability concerns

Commenters raised several points:

• "In my opinion, all of these open source/free/open document signing tools are neat on paper ... but won't take off in any meaningful way legally because there's no entity behind them taking the responsibility for accuracy and culpability." – @JCBird1012

• "Nice idea but with all related things the ultimate question remains whether courts will actually recognize it. Currently courts will still consider paper‑signed and scanned PDFs as legally binding..." – @qurren

• "Loved it until I saw its using Bitcoin. With proof of work doesn't it tie this project to a bit of an environmental nitemare?" – @evolve2k

• "I don't like the idea of this using bitcoin. I wonder if it's possible to build this off of regular PKI - certificate transparency logs for instance encode the proof of commitment..." – @conradludgate

• "Challenge with this domain is the TRUST anchor. As an organization/company you have to establish yourself first (directly or through reference) otherwise its hard for anyone to trust you." – @sandeepkd

• "Looks interesting, but in order to actually compete with any e-signing platform you'll at the very least need to have templates with pre-filled information, an API to autofill docs with required information, and more field types." – @mfkp

• "It's a neat proof of concept, but it's hard to see the organizations that care about certified documents adopting this. Inherently conservative." – @1123581321

• "You can't be the 'Let's Encrypt of' anything if it's self-hosted. The entire point of Let's Encrypt is that there is a centralized reputable entity of note signing everyone's keys." – @vitally3643

Others noted the similarity to existing projects (DocuSeal, Open Claiming Protocol) and asked for clarification on the Bitcoin‑anchored root versus RFC 3161 timestamping.

These comments show enthusiasm for the technical approach but also skepticism about legal adoption, trust establishment, environmental impact of Bitcoin proof‑of‑work, and the need for richer e‑signing features such as templatable fields.

The project is open source under Apache‑2.0

The engine, SDKs, and the SEAL specification itself are released under the Apache‑2.0 licence. Let's Seal is maintained by nsokin as a project of Experimental Open Works, run as a public‑benefit foundation so the standard cannot be pulled behind a paywall.