Autocrypt support for kmail
Open, Needs TriagePublic

Description

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 https://wiki.gnupg.org/AutomatedEncryption 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

As Thunderbird and k9-mail (Android) support autocrypt it would certainly make things a little easier when using email encryption and making it a little easier isn't a bad thing.

Whishlist bug report about autocrypt support:

Bug 388036 - Include support for autocrypt
https://bugs.kde.org/388036

Good to close in case of implementation.

Encouraged by the Junior label and heliosmartins reference, I'm looking into the Autocrypt spec to see if this is something I could do (I do not know what the Junior label specifically means or how it was determined). Adding a header to all outgoing emails seems fairly straightforward. For retrieving mails, which was classified as 'advanced' in the task, I'm trying to flesh out the work needed a bit more. I have zero Kmail or KDE coding experience (a bit of C++ I do). The Autocrypt spec does seem quite well worked out such that I only have to think about the best integration into Kmail.

With regards to updating keys: the default behavior in the Autocrypt spec seems to be to auto-overwrite the previous key in case of receiving a new key (in a message which meets all the requirements to prevent auto-accepting a wrong key). See bottom of this section.

I think the main thing is that Kmail now uses an external PGP client, and PGP trust levels. Autocrypt has no trustlevels afaics (just the binary prefer_encrypt), but Enigmail and K9mail implemented a trust level on top of that (one can chose to trust a key, which then drops to untrusted upon the auto-overwrite of a new key. Is it necessary to map this to the 6 trustlevels of PGP, or should Kmail keep this 'rating' separate and only use the PGP client as a keystore?

Since auto-overwriting keys are Autocrypt spec, I suppose the enabling of Autocrypt is MUA-wide, not, for instance, per identity. If Autocrypt support is enabled upon a new checkbox under Identity > Crypto, another identity may still override the key of a communication peer which is perhaps communicated with another 'non-autocrypt identity'. I think this solves the all possible conflicts between Autocrypt defaults and PGP defaults or expectations: by enabling Autocrypt the user gave consent to these behavior MUA-wide.

Another question is how this task relates to T2520, which is about opportunistic encryption. I don't know if any code came from that, but I guess the same sort of GUI implementation for trust-levels could and should be reused.

What are your thoughts?