alt Hacker NewsShow HN: Let's Seal – Let's Encrypt for document signing, free and self-hosted
TLDR, Let's Seal gives the finger to Adobe and every doc signing tool (docusign, google, etc) who pay to play with the Adobe Approved Trust List and then charge you for something that should be free.
Currently even the person checking if a document/contract is sealed or code is authentic has to also be inside the same Adobe walled garden too. Verification, the part that should be free is the part everyone charges for. Thats the shape Let's Encrypt fixed for TLS, and I wanted the same thing for documents and files.
The core idea therefore needed to go a bit beyond e signatures and i created an open standard (SEAL), plus free tools that implement it.
When you seal a file, three independent things happen.
1. it gets a signature from a certificate authority, chaining to a public root. 2. its record is appended to an RFC 6962 transparency log. and 3. its SHA256 is timestamped on a public blockchain (Bitcoin) via OpenTimestamps. Those three give you integrity, transparency and a timestamped proof. And importantly, none of those depend on Let's Seal and none are gated.
You can verify with the tools you already have, no Let's Seal account and no Let's Seal software. A sealed PDF carries a standard PAdES signature, so any PDF reader validates it. A sealed build artefact carries a cosign compatible signature and a SLSA provenance attestation. The Bitcoin timestamp verifies with stock ots.
3 ways to use it.
1. The free web app. We kindly have backing from Backblaze to cover storage costs for the foreseeable. So you can upload or issue any number of documents, get a public proof page at /d/<hash> and verify it at https://verify.letsseal.org for free. Multiple accounts, multiple seats, enterprise functions. Free.
2. Self host the whole thing. Apache-2.0, one Next.js app plus a signing service that holds the CA key on localhost. Storage is any S3-compatible bucket or local disk. If you'd rather run your own root of trust, you can.
3. Programmatically. via the CLI and a hosted API. This is the Let's Encrypt/certbot angle. Seal or anchor things from CI, or have a backend seal every invoice or report as its generated.
The CLI is sealbot. It runs anywhere Node runs (npx sealbot) and there are native binaries for macOS, Linux and Windows with no runtime needed.
Theres a GitHub Action wrapping the same tool, so a release workflow can seal its own artifacts. Its what proves our own releases.
KYC is semi-handled (to a degree) it's hard to do for free (at least for now), but issuers (your companies or websites) domains can be authenticated with a DNS record added, which proves the issuer has control over a domain. Sign-in can be authenticated to an email via Google Sign in and a few others will be added to the web app in time (Same as Docusign currently). Ideas welcome on future KYC should there be a demand.
Feedback welcome on the standard (SPEC.md in the repo).
Repo: https://github.com/letsseal/letsseal Site: letsseal.org
Thx
Comments
Why not use RFC 3161?
Due to how the code signing works, timestamping servers are provided by all major CAs with full public access, e.g. timestamp.digicert.com, timestamp.comodoca.com, timestamp.sectigo.com, etc.
PS. OP, your comments are auto-killed for some reason. You may want to message mods to get this sorted.
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, so any verification on top of that is superfluous to them.
More realistically, you take an oauth when you take the stand at the court, and if a signed document was altered by the counterparty you'd say so truthfully, if it weren't, you'd say so truthfully, and the penalty of that oauth purjury is high enough that most people wouldn't do it. Cryptography not needed.
Tried to poke a little to see if I can find any name (I could not). 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.
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? Bitcoin isn’t the best place for this, no?
I would have imagined Ethereum or some other ledger would have been better no?
Anyone with more crypto ledger knowledge be able to say what I’m trying to say more precisely.
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. Right now for example, you can only add text, checkbox, and date/signature fields. Checkboxes are required to be checked (no making them optional), so if there are multiple checkbox options, they have to check them all to continue. Not very useful for actual e-signing flows.
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, while the signature can be an X509 certificate.
It’s a neat proof of concept, but it’s hard to see the organizations that care about certified documents adopting this. Inherently conservative. Let’s Encrypt invested a lot in their early partnerships and used that to sneak up on the conservative buyers and trusters of certs.
I love the concept, it would be great to see broader uptake of an open standard for this sort of space.
I'd be very careful with this. Looks to me like an invented standard: https://letsseal.org/site/standard
Poked around a bit..excited to see where this goes.
Just a quick note, Under "Get help from the community > Disucssions", there's a 404 to https://github.com/letsseal/letsseal/discussions .
The idea makes sense in principle I think, and but I'll be chewing on it a bit, haha. Seems like a solid standard, but you know how standards go.... (Relevant XKCD: https://xkcd.com/927/)
I like that you kept a lot of the same commands/naming/syntax from LetsEncrypt. As someone familiar with LetsEncrypt, makes me feel like I'd slide right in here easily.
I'd like to learn more about the 'Bitcoin anchored root'...is that part of RFC 6962 or something else entirely? Do you mean a 'Bitcoin-like blockchain' or are you using the actual BTC chain? Could you point me in the right direction?
Is this PAdES B-B only? As far as I know, PAdES B-T requires a QTSP timestamp.
In my opinion, all of these open source/free/open document signing tools are neat on paper (and technically fulfill the goal of being able to verify a document's chain-of-custody/signature provenance) - but won't take off in any meaningful way legally because there's no entity behind them taking the responsibility for accuracy and culpability.
DocuSign/Adobe/whomever is trust anchor, it's an entity you can sue or subpoena if something goes wrong. Someone who's actually on the hook for making sure whatever's signed is accurate and truthful (outside of the reputational risk of fraud completely obliterating any trust in your platform)...
No amount of cryptographic verification substitutes for having a legal person on the other end who can be held accountable for actually verifying the document was signed accurately/process was followed.