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.

Related Objects

StatusAssignedTask
Opensebas
OpenNone
knauss created this task.Tue, Apr 3, 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.