mailcow / mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕
https://mailcow.email
GNU General Public License v3.0
8.96k stars 1.18k forks source link

Web Key Directory #4273

Open mhupfauer opened 3 years ago

mhupfauer commented 3 years ago

Summary

Would it be possible to implement web key directory, so that users may publish a pgp key others can use to send encrypted messages.

Motivation

This would lower the general hassle attached to sending pgp encrypted email

Additional context

I currently implement this on an additional web server, however it would be nice if mailcow could serve these requests.

mkuron commented 3 years ago

Good idea. According to https://wiki.gnupg.org/WKD there is some client support for this already. It‘s not an approved RFC yet, but that will probably happen soon. An implementation in Mailcow could look roughly like this:

  1. Add the necessary SRV record to the DNS page.
  2. Check if the records are present. If yes, display a field on the user page where the user can paste their PGP key. Store that key in the user record in the database.
  3. Implement the web service that delivers the keys at the well-known URL.

Since you already have experience with WKD: would you be interested in trying to implement it in Mailcow?

mhupfauer commented 3 years ago

@mkuron There is a new IETF draft for this protocol that replaces SRV records with a .well-known folder on openpgpkey.domain.tld. https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/

Therefore the url can be constructed by clients without need for dns resolvers that support SRV requests. https://openpgpkey.[domainpart]/.well-known/openpgpkey/[domainpart]/hu/[localpart ==> SHA1 ==> Z-LIB-32]?=[localpart]

However as I really don't want to implement the whole email automatism, I'd propose to allow users to upload the keys themselves via the portal.

Therefor only the subdomain openpgpkey. would need to be added. Some logic would be needed to handle the URI .well-known/openpgpkey/[domain]/hu/ and generate the appropriate key id.

I have some time after Tuesday so I could look into it how complex this would be to implement.

mkuron commented 3 years ago

The advantage of the SRV method would have been that it would not have required an additional subjectAlternateName in our TLS certificate for every domain. Now you will need to also add that to our Let‘s Encrypt handling. And we probably can‘t turn it on by default because it reduces the number of domains that can fit into a single certificate when ENABLE_SSL_SNI isn‘t turned on. But we can figure that out later.

strarsis commented 3 years ago

I really want to start signing/encrypting my email using something like PGP. Not everyone uses it, but it can help raising awareness, as the MUA may show a message about it.

mkuron commented 3 years ago

Not everyone uses it, but it can help raising awareness, as the MUA may show a message about it.

It's probably not going to help with that as MUAs probably won't perform WKD lookups unless a private key is present, which the user would have actively created and thus be aware of PGP already. WKD would be highly useful though for automatic key lookup, now that PGP key servers are essentially dead.

mhupfauer commented 3 years ago

I think we need to clearly separate here: WKD is the pub-key lookup component, where senders (likely external) can fetch the key of the receiver (user on mailcow) if they have uploaded it to the UI.

kenayagi commented 2 years ago

Has any progress been made on this feature? 🤔

wildy commented 2 years ago

Also, this is a duplicate of #2762.