Autocrypt support for kmail
Open, Needs TriagePublic


Autocrypt makes it easier to communicate end-to-end encrypted via mail. Thhe basic idea is to have a additional mail header "Autocrypt". Within this header you send your gpgkey and your encryption policy. The goal is to have everytime the gpgkeys you need to reply.

They also added a way to transfer your secret gpgkeys between devices.

Related Objects

knauss created this task.Apr 3 2018, 9:24 AM

I'm not against it as such. Anything to grow and improve the OpenPGP / Mail Crypto ecosystem is good as long as it is compatible. But I do not like the Autocrypt concept very much.

The design decisions of Autocrypt were / are made on private meetings. We tried to argue / discuss the concepts in mails and were mostly ignored.
I don't see the need to send a public key in the header, If a MUA sends signed mails by default and a key is published either through WKD or on a public keyserver it is redundant and enlarges the mail without necessity. If you have a signed mail you already know the fingerprint of your communication partner and can grab that from a keyserver.

Similarly I find it more important to track if you have received a signed mail from a communication partner, then you can be pretty sure that you can encrypt a mail to that key and the communication partner can read it. Autocrypt also does not make any assertions about trust. As I understand it they declare trust out of scope and only want to promote encryption by default. Don't get me wrong, this is a good goal. But I think that we can do more.

Speaking for the GnuPG Project, our favorite concept is still even with the projects for this finished we are still working on it based on donations. For Gpg4win 3.1.0 I've started with a new Keyresolver in Libkleo, as a first step it does not do much more then what is really required for our Outlook Mail Extension. The change to this was already traumatic enough ;-). But for 3.2.0 we are planning to extend this further to have more automated encryption support. The API is designed in a way that should allow KMail / KAddressbook integration. Maybe take a look at libkleo/src/kleo/keyresolver and libkleo/src/ui/newkeyapprovaldialog .

One of the things we are missing in GnuPG for example would be to have it change the trust model for a Context, as I don't see how you can provide a good user experience with "TOFU" trust for file crypto, but I want to use it for Mail crypto.