mailcow-dockerized
mailcow-dockerized copied to clipboard
mailcow
Web Key Directory
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.
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:
- Add the necessary SRV record to the DNS page.
- 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.
- 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?
@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.
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.
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.
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.
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.
