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.

for sending mails

Autocrypt uses a special header named Autocrypt with the complete keymaterial It is quite straightforward to just add this header to a mail we want to send. With following format:

Autocrypt: addr=alice@a.example; prefer-encrypt=mutual; keydata=...

later on we want also add the Autocrypt-Gossip header to support 1:N communication.

for retrieving mails

to make usage of Autocrypt we need to understand the autocypt headers and interpret them correctly. This is a more advanced task, as more parts in KDE PIM needs to been touched. Additionally we need to think about how we dispaly the information to the user. Especially if the keys differ from what we have in the keyring.

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.

knauss updated the task description. (Show Details)Aug 19 2018, 1:12 PM

I'm also with you aheineke, that this Autoencrypt is not the smartest solution for email encryption. As Thunderbird already sends those headers it is very good if we support it, too. And I see some gain in some usecases where Autoencrypt makes the life easier.

knauss moved this task from incoming to Technical on the KDE Privacy Goal board.Mar 25 2019, 9:13 PM