The API is designed in a way that should allow KMail / KAddressbook integration. But for 3.2.0 we are planning to extend this further to have more automated encryption support. The change to this was already traumatic enough -). 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. 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. As I understand it they declare trust out of scope and only want to promote encryption by default. Autocrypt also does not make any assertions about trust. 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. If you have a signed mail you already know the fingerprint of your communication partner and can grab that from a keyserver. 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. We tried to argue / discuss the concepts in mails and were mostly ignored. The design decisions of Autocrypt were / are made on private meetings. But I do not like the Autocrypt concept very much.

Anything to grow and improve the OpenPGP / Mail Crypto ecosystem is good as long as it is compatible.

Autocrypt connected