removing the background color makes it less obvious, that it is actually encrypted and user will overseen it more easily. For me personally I like the green background :D But for sure we should rework when we show what color and also if we show red for a technical problem too.

But anyways, with the current refactoring the last weeks we can now easily change the visual represation for mails and can create multiple render profiles. So maybe we wanna start with secod profile to try out other visual represations.

I'm OK with removing the background (especially the red/yellow one).

I think it would be enough just to show an indicator in the headers, some sort of a button that would popup the key dialog with details, something like this:

Sandro, could you expand on how to create and use the different rendering profiles please? I think it would make sense to have a secondary "development" profile where we can play with things before we merge them to the public one.

I like your mockup from a usability standpoint (although I think signed might be better worded as "Sender verified as") Outlook and Enigmail do it this way. But technically this won't work. As we can have multiple (infinite) PGP Message parts in a mail with different encryption / signature states. :-(
I think Outlook only shows a valid signature if the mail was completely signed by one S/MIME certificate. This leads to so many invalid signatures (at least in my tests) that I guess most users just ignore the invalid signature marker.

Enigmail is worse, you can currently trick it into displaying the wrong signer ( https://sourceforge.net/p/enigmail/bugs/581/ ) If only a forwared mail is signed because it does not indicate which parts are signed.

I can't think of another way to solve this then by keeping the inline "boundary markers".

In GpgOL where I don't have the option to use inline markers I solved this by only displaying the first signed part and ignore the rest (So that I can show only one signature indicator). But this is not good and KMail should have the best crypto support possible. :-)

Mh thinking about Björn Balasz telling me design for the 90% use case and not for the corner cases it might be a good solution to just show such
an overall indicator if it is applicable (everything was signed / encrypted and with the same keys) and show the part boundaries in the corner case where only some parts. E.g. a forwarded mail was signed by another key. Maybe Björn has a good idea for this problem :-)

Btw. a classic case where only some parts are signed are mailing lists that add their mailing list footer to a message.

I've reworked the signature status display in the Outlook pluging for GnuPG where and also added some basic TOFU support there. I've written down my thoughts on validity under https://wiki.gnupg.org/EasyGpg2016/Validity

The code I use in GpgOL to determine if we have a "Valid sender" is:
GpgOL Git repo

Turns out there is more to it, the UIValidy page brought us back to rethinking everything in Context and what we actually want to have. E.g. Designing a "Usable Conflict Dialog for TOFU" caused us to rethink the whole a recipient has to resolve a conflict design.

It's now at:
https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption
This page is was written together with other GnuPG developers and I think we can say it's GnuPG's take on Automated Email Encryption. Not written in Stone but there is general consensus about most points and I don't think its far from finished anymore. You should read at least the part about the Level's the conflict resolution stuff is more about "sending" and I'm currently looking into this.

Some things were already changed in GnuPG e.g. the TOFU Validity so that we no longer need to have our own Threshold but some things won't make it into GnuPG soon, e.g. the Level's or source trust. Source trust will be added soon but the level's won't. They are more of a UI thing. I think this task is now more about implementing the Signature Display / Status as outlined in that concept.

We've used GpgOL as a playground / prototype for this. KMails UI will of course be different (In Outlook I'm very limited) but in general I think starting from level 2 we should show signatures as green. I would have liked to put the signature status Icon closer to the "From: " in the UI but this was impossible. I don't want to give to hard requirements how it should be implemented in KMail as I also needed Serveral Iterations in Outlook to find something that works. Screenshots of this are linked at the bottom of the wiki page.

Code is now in GpgOL master:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=blob;f=src/mail.cpp (see Mail::get_signature_level () / Mail::get_crypto_details () )

Maybe get_signature_level would be something for GpgME++ but the only really complicated thing about the level order is the "Direct trust" Level which gnupg currently does not provide and needs the information about the available secret keys.

Please let me now if you have comments / questions regarding the Automated Encryption concept. We could also discuss this on gnupg-devel@gnupg.org .

Hi,

thanks for the link. A summary and a task list for me follows, feel free to correct me if something is missing/wrong:

1. Implement trust levels in libkleo - int Kleo::trustLevel(const GpgME::UserID &id)
2. Adjust signature handling in MessageViewer based on the trust level of sender's key
   • Level 0: no trust indication
   • Level 1: no trust indication, a "Details" link that shows details about the signature used
   • Level 2: marginal trust indication (yellow frame around the signed part)
   • Level 3: full trust indication (green frame around the signed part)
   • Level 4: full trust indication (green frame around the signed part) (@aheinecke: should we distinguish from level 3? How?)
3. Adjust auto-encryption in Composer based on the trust levels of recipient's key
   • Level 0: don't auto-encrypt
   • Level 1: auto-encrypt
   • Level 2: auto-encrypt
   • Level 3: auto-encrypt to level 3 (@aheinecke: how is this different from level 2 "auto-encrypt"?)
   • Level 4: auto-encrypt to level 4 (@aheinecke how is this different from level 2 "auto-encrypt"?)
4. Key auto import/refresh
   • When composing we use KeyForMailBox to retrieve the key. The document suggests we should occasionally check if the key is still valid/up-to-date in WKD. **@aheinecke: should KeyForMailBox do this? Should we do this? How often?
   • When message is received: import key from WKD, if unknown,
5. Implement conflict handling
   1. When composing
      • two matching keys for single email address, but we have private keys for both -> suggest cross-signing (and automate it)
      • two matching keys for single email address, but we don't have private keys for them -> follow the pseudo code described in the wiki
   2. When checking an received email
      • received email signed with a new key, but we already have a known and trusted key for the same email address -> try to find the new key in WKD. If found, set trust level to 2, otherwise alert user about possible MITM/phishing attack

Did I forget anything? Did I understand the document correctly?

Hi,

In T3128#74231, @dvratil wrote:

1. Implement trust levels in libkleo - int Kleo::trustLevel(const GpgME::UserID &id)
2. Adjust signature handling in MessageViewer based on the trust level of sender's key
   • Level 0: no trust indication

For Level 0 I also see some Details link because the mail was signed but we know nothing about the Key. It is either not there or Web of Trust trust is used but the key was not signed by any trusted Key. We need to offer Details here to give the user the opportunity to sign the key.

• Level 1: no trust indication, a "Details" link that shows details about the signature used

Question about the Details:
I currently see two details:

1. A short text explaining "Why is this Level X?"
2. Details about the used key (Kleos Key Details dialog)

So probably some "Details" like we currently have containing the text. And in that Details text a link to the key.

• Level 2: marginal trust indication (yellow frame around the signed part)

I would like this "green" already. It's fairly strong, either HTTPS trust / TOFU Trust or Web of Trust marginal is used. KMail currently also shows Green for Marginally trusted keys and GPGME returns sigsum "Green". So we would not "lower" the requirement for green. We would actually make it higher because KMail currently shows Level 1 as green already when TOFU is enabled.
I would like to avoid yellow completely because yellow is a warning color and as long as we don't want to put a yellow frame around unsigned mails we should not warn more strongly about signed but not fully trusted mails.

• Level 3: full trust indication (green frame around the signed part)
• Level 4: full trust indication (green frame around the signed part) (@aheinecke: should we distinguish from level 3? How?)

Level 3 and 4 are in our opinion levels that require Training, either through guides or in an institution. E.g. Only transfer money on Security Level 3.
There will probably be a requirement for German Restricted Documents that they may only be sent to keys where direct trust was used as the requirement is to check the key through a different channel and verify the fingerprint (lsign / certify)

Level 3 is the S/MIME level where "certificication" happend. Either by a CA or by the Web of Trust for OpenPGP so someone else. Level 4 is where the ceritification happend by yourself. Level 4 is also for your own messages.

I think it's ok to distinguish between them by wording In GpgOL I also used different Icons (Level 4 has the "star", Level 3 is the checker).

1. Adjust auto-encryption in Composer based on the trust levels of recipient's key
   • Level 0: don't auto-encrypt
   • Level 1: auto-encrypt
   • Level 2: auto-encrypt
   • Level 3: auto-encrypt to level 3 (@aheinecke: how is this different from level 2 "auto-encrypt"?)
   • Level 4: auto-encrypt to level 4 (@aheinecke how is this different from level 2 "auto-encrypt"?)

No difference between levels 1-4, The Keys should show more valid but that we already do with the Icon next to the recipients. Maybe

1. Key auto import/refresh
   • When composing we use KeyForMailBox to retrieve the key. The document suggests we should occasionally check if the key is still valid/up-to-date in WKD. **@aheinecke: should KeyForMailBox do this? Should we do this? How often?

This needs to happen in GnuPG because the Key needs to be refreshed also when we are not using it. So no change for us that I currently see.

• When message is received: import key from WKD, if unknown,

No change for us. GnuPG already does this when "auto-key-retrieve" is set.

1. Implement conflict handling
   1. When composing
      • two matching keys for single email address, but we have private keys for both -> suggest cross-signing (and automate it)

I think this needs to happen in the Keyresolver class because we also need this when Opportunistic encryption is not used. T5050

• two matching keys for single email address, but we don't have private keys for them -> follow the pseudo code described in the wiki

This needs to happen happen in GnuPG. What the KeyForMailBoxJob does in the end is that it calls "gpg --locate-keys" which does only return one Key in Versions since 2.1.16 so we would not even see the second key. (Except in the KeyCache). The whole algorithm in KeyForMailBoxJob is now in GnuPG but I left it in GPGME for compatibility with older versions.

1. When checking an received email
   • received email signed with a new key, but we already have a known and trusted key for the same email address -> try to find the new key in WKD. If found, set trust level to 2, otherwise alert user about possible MITM/phishing attack

The WKD part should happen in GnuPG. If we have a conflict we show that mail as Level 0 and in the Key Details we say something about the conflict and add a "Use this key for encryption" button that changes the TOFU Policy from "ask" to auto and sets the Policy of the other conflicting key to "bad".

Did I forget anything? Did I understand the document correctly?

I think a problem is that the Document currently does not make it clear enough what should happen in the MUA and what should happen in GnuPG. I'll try to improve that. The only misunderstanding I see was the meaning of Level 2

@aheinecke with the missing "key source" feature, most of my keys that don't have TOFU history (yet) fall into trust level 0, because they have marginal trust and no TOFU, so I only get auto-encryption enabled for fully- or ultimately-trusted keys. Should we roll with that?