Ask HN: Why isn't there something like Let's Encrypt for document signing?

There are cheap s/mime CAs out there. It should be possible for LetsEncrypt to issue an s/mime cert for a domain, similar to TLS certs and verified in the same way, despite what top comments here are saying.

S/MIME being made for email, you can use port 80 ownership, or dns record ownership to verify control. And documents can be signed as originating from bob@acme.com.

I have implemented s/mime to sign documents automatically between companies. It is the best option that works by default. Powershell and openssl support it, as does outlook for email.

My guess is they don't see enough people asking for this, because those who need what you are asking don't mind paying cheap CA fees like $15/year or so.

Document signing is NOT a technical problem.

It's a legal acceptance problem - and everyone KNOWS docusign and friends and understands how they're admissible. Anything else would have to compete with that and people would be suspicious of it for a long time.

The best way for something like LE for docusign to start would be via a government office of some sort.

Someone said it already: it's not a technical problem. This is a business problem, which means it's a social/psych thing. >= VP-level generally[1] don't recognize the signed doc as a signed doc. Unless they see that little A arrowhead in the top bar.

W3C and Google aren't helping things here; by drip-feeding PMM into CSS, they've made it impossible to get a consistent HTML5-based print standard. Which could then be wrapped in "normal" auth0. However, I don't know the details of the whole shebang, all I know is that PMM3 was in the works in 2006 and it never quite came out of its hole. Instead you have to shovel out money to Prince or figure out how Paged.js works. But whether or not that's W3C or Google's fault, I really don't know. Maybe HN could edukamate me.

[1] Particularly the older ones that think they're hip. Others just let their tech-savvy assistants sign everything.

Aside from what others have mentioned, the wonder is actually that there's something like Let's Encrypt itself. It was a huge lift by the LE founders/engineers/benefactors to pull it off, and they had a larger mission to make the web more secure for end-users. Document signing has no such larger mission, so any players have to do it either for money or for the lulz, which won't get to LE benefit and scale.

You could probably use Sigstore[1] for this: it's a free, publicly run CA and transparency log that ties signatures to OIDC identities, meaning that verifying a signature doesn't require maintaining a long-term keychain -- you can simply ask whether the input was signed with the same email identity that mailed it.

The project is currently more focused on software signing, but it's generic over any input under the hood. The bigger challenge here would probably be mucking with whatever signature envelope PDFs use, and ensuring that existing PDF verification tooling can consume Sigstore signatures.

FD: I'm involved in the Sigstore project.

[1]: https://www.sigstore.dev/

SMIME certs for email are to my knowledge the most relevant analogy for a “web pki for users”. There is no ACME-over-email for SMIME that has made it out of rfc into practice, so that is the first hurdle. Hurdle #2 is there is only relatively weak agreement (AFAIK) on a “internet trust bundle for SMIME CAs”. Hurdle #3 is likely a lack of modern amenities like CT for SMIME CAs.

You can just send a signed pdf over email. Perfectly legal.

Macs even have a terrific signature attachment feature in Preview (the default pdf viewer).

Docusign etc. just add version tracking and document management, but you can just back up email. Even at some scale. Docusign is like buying a picture frame for a document like a diploma, it looks a more official but doesn't change anything.

electronic document signing as a concept is covered by many software patents

if you started your own product doing it you would get sued by DocuSign and friends, and they have lots of money for lawyers

so quite hard to disrupt their monopoly

Could you abuse LetsEncrypt as a content signing service? Take the information you want signed, including a timestamp for good measure, and of course some form of your identity, generate a secure enough hash for it, use that as a sub-domain and get a certificate for it via LE?

So my document plus meta-data like my legal name & email address hashes to b8e24cce6743bf2d86195d1781b068b6fdf1e12a413eb61c16e32e1e5f64f5cc, I get a certificate for b8e24cce6743bf2d86195d1781b068b6fdf1e12a.413eb61c16e32e1e5f64f5cc.sha3-256.docs.mydomain.tld from LE (extra “.” due to the 63 characters per name part limit in DNS specs). By handing over the certificate LE has effectively signed to say that hash was presented to it at that time.

The fact the certificate expires in three months is not relevant: that hash was signed at that time, so it must have been generated then or before then, and it is mathematically impossible (assuming a good hashing algorithm was picked) that when challenged at a later date that I managed to manufacture content that hashes to that value and looks like what I'm claiming to be legitimate & extant at the relevant time, and it is similarly implausible that I forged a certificate that looks like it was signed using one of LE's signing certificates.

Of course the next challenge is convincing people that the certificate means this, and that fact is legally meaningful (assuming, for instance, the “signature certificate” is being verified to prove you created the content before someone who claims something more recent of theirs is prior art).

You also need to stay within LE's limits, so if using only one domain that is at most 50 signed documents per week if you do each individually. You could batch the documents to be signed up in a single set and hash that instead of individual documents, so if you are happy with daily granularity that is only 7/week. If sticking to a regular interval with nice round numbers you can get approx 4-hour granularity (4 signing timeslots per day, so 42 per week, leaving you 8 in case there are circumstances where something time sensitive wants signing right this instant).

Depending on the use case, OpenTimestamps may be relevant. They also have a long list of member organizations/companies that might provide a more relevant solution for you.

https://opentimestamps.org/

In my company, we are building a new free product, Kentro Sign, which his a document signing based on Corda blockchain. If you want to try it, it's free (not even a free tier) and it's there : https://sign.kentro.network/ .

Feel free to give back any feedback. I am a mere DevOps Engineer, but I will forward it !

Document signing is about verification of authenticity of origin of author. LetEncrypt does not do this, not even for websites. I can get LE certs for millions of end-points I do not own due to the way many cloud providers abuse DNS and sub-domains. Some people do this day and night as a way to make a buck on the side from bug bounties. One of them I will never forget as he adds pictures of cute puppies to corporate websites.

The only open source answer I know of is probably not what you want as it would require every party to participate and would require a little setup thus not making it widely adopted. Documents can be signed with GPG but this alone is useless. Every party involved would need a way to publish their public keys and prove that each party actually created said keys. This to me implies inclusion of a public notary in the process. None of this matches your requirement of widely trusted not to mention the added friction. The original method of getting EV certs proves that people will not do this. It used to require a notary Now I can just give a Dun & Bradstreet number and some money to get one.

To my knowledge there is no widely trusted document signing system nor do I expect that to become a thing unless a service that people already use started implementing what I described above. I could see one or more banks offering a service like this. Many already have public notary services.

There are services like Docusign and Docushare as others mentioned and they are used and abused by lawyers and realtors day and night. I honestly do not see any added value by these services beyond being lazy-friendly. If I log in using my email address and click a button that adds a cursive signature that I did not create, that is not really proof of anything. Anyone that could intercept my email could impersonate this. I expect these services to be legally challenged and dissolved in the future for lack of attestation, especially when a future high profile case involves powerful political and corporate persons having to prove they did not embezzle money. Covid made them super popular but I was very surprised to see the legal documents I could get away with clicking in signatures with no other evidence it was me that did this. I am not a lawyer but I am not sure that matters in this case.

In my opinion if you have important documents that you want to prove were signed by you then my suggestion would be to see if your bank offers free public notary services and have them notarized. The page containing the signatures and the notary/bank information can be scanned as part of the document set.

[Edit] I should add that some of the bigger banks will only offer free notary services if the account holder has one of their special accounts. They usually have the name Premier or Priority or some other glorified name.

https://keybase.io/ maybe?

Many governments have implemented this.

Secure communication implies three things: 1. the involved parties verify each other's identity, 2. communication is not compromised 3. the communication isn't spied on. The problem with self-signed certificates is that browsers can't establish (1), so they complain. Let's Encrypt really only solves the problem of browsers complaining, but it doesn't verify the domain owner's identity (eg. no credit card check).

I think document verification should be more stringent: you want to be sure whoever signed a document is who they claim to be and have the authority to do so, not just that they owned some domain and got a free certificate.

we have it in EU, IIRC eIDAS directive. Anyone in EU can digitally sign and verify documents

Here's how someone can do it.

LetsEncrypt exists because identity in SSL/TLS is only about domain name ownership, which is easily checkable using automated scripts if you handwave away the question of how to securely connect to that domain without TLS - ultimately it needs DNSSEC to be theoretically sound but in practice we cross our fingers and hope for the best without it.

The standard PKI is not a monopoly, it's the opposite. It's a competitive market with several players (vs SSL certs where LE just totally dominates due to being subsidized). CAs will sell you certificates usable for PDF document signing but they have to charge money because there is no automated way to verify your legal identity, so manual labor is required and that's expensive.

Therefore, the problem of how to build a LetsEncrypt for data is the problem of how to verify identities at scale automatically. There are two possible approaches you can use here, all of which require new software or infrastructure (which is why it hasn't happened).

1. Sign documents with your domain name! There is no specific reason you can't use an SSL cert to sign a document, it's just that the certs have flags in them that say they're not meant to be used that way. But a key is a key. You can write software that will override those checks and then use the regular standards like CMS, Authenticode or PDF signatures. This could work as long as you domain name was the same as your business/project name, or otherwise unique to yourself somehow. But judges would have to accept it. In the USA it's possible because the law doesn't say much about the exact nature of digital signatures, in the EU it's probably not because the Commission has spelled out in excruciating detail exactly how the PKI and signing specs must work.

2. Verify identities using e-Passports. Every e-passport contains a signed certificate holding your personal data signed by government root authorities, including a JPEG2000 encoded image. To automatically issue a certificate against such an identity, you need:

2a. A mobile app that can dump the NFC chip contents. This is done already, you can find such apps on the Play store (dunno about iPhones though). The data in the chips are public, it's not locked down.

2b. Some way to verify that the person with the public key is the same as in the passport photo. This can be done with face recognition/matching AI.

2c. Some way to re-assure people that uploading their passport contents to a remote server isn't a dumb thing to do. This can be done by running the CA and verification logic inside an SGX enclave, with open source clients (e.g. the mobile apps) that verify the enclave's remote attestation before uploading anything. The data will be encrypted and protected from the owner of the CA hardware.

Now you can create a PKI that auto-issues certs with people's public key, legal name, country and maybe photo in them. The enclave can also issue sub-certs that reveal less information or even certs that use a keyed hash of the passport number or something to give you an anonymous yet unique credential. Of course this new PKI won't be recognized by Windows, PDF viewers, governments or anything else that consumes signatures. That's step 2.

Or for code signing