Shows emails from keys with very strong trust as untrusted
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
#399 Shows emails from keys with very strong trust as untrusted
While explaining gpg and enigmail to a new user, he got very confused when enigma showed an email from me that was signed as somehow untrusted, even though he just set the trust level to 'very highly verified' (in Cleopatra, part of GPG4Win).
Some debugging showed that the problem was that Cleopatra does not allow ultimate an ultimate trust setting, but instead stops at the level one below that trust, while enigma doesn't trust any signature below ultimate trust.
The shown sentence in german is something like 'Unvertraute korrekte signatur' - but unfortunately it is very easy to read as just 'untrusted *' (i.e. something's broken, GPG doesn't work)
There should be a better user experience when using Enigmail together with gpg4win - so one of the two tools should change how it deals with trust levels. Being just a casual user of gpg, my guess is that Enigmail should change to allow 'very carefully checked signatures' as valid.
Related
What you write is not exactly correct. Enigmail does not do anything with the trust level - that's done by GnuPG. Your problem is that GnuPG calculates a trust level (Calculated trust) based on the "Owner trust" (which is what you set) and the signatures assigned.
Simply assigning a high owner trust without any signature results in a marginal Calculated trust. That's to blame to GnuPG, not Enigmail - we simply display what GnuPG reports.
Kleopatra bug: https://bugs.kde.org/show_bug.cgi?id=343703
While I value your point of view - this is really something that you guys will have to make sure is fixed, as otherwise nobody will.
So I would strongly advise to track this bug in your bug tracker and make sure it is fixed - no matter where that has to be. Just saying that it's someone else's problem doesn't work.
Well, no -- that is the concept in GnuPG. You may like it or not.
To quote: "problem is that GnuPG calculates a trust level (Calculated trust) based on the "Owner trust" (which is what you set) and the signatures assigned."
That I think is wrong. My problem is that I just received an email and want to check that it is signed with what I think it is. Your problem is to build a UI that does not require every new user to get a complete and correct mental model of GPG - BEFORE he can even start using Enigmail.
Last edit: Martin Häcker 2015-02-02
On Mon 2015-02-02 12:18:42 -0500, Martin Häcker wrote:
in gpg, what Patrick is calling "Calculated trust" is actually called
"User ID Validity", or just "validity".
This is a long-standing confusion, and Enigmail would do well to replace
its validity indicators with "valid" instead of "trusted". A few days
ago at a workshop, I saw a sophisticated user setting ownertrust with
enigmail because they thought they were setting validity. This is a
dangerous mistake :(
As a constructive thought: I think it would be very helpful if the display in Enigmail would change a little bit.
If it showed first that the signature is correct and that it is in the keychain and marked as 'I have checked it thouroughly'. Then after that it can say that no web of trust trust chain to that key could be established and that that is something that you should do to further secure the communications.
That would accomplish that the confusion about the status of that key is much reduced, while still educating users about what GPG considers the holy grail, getting a web of trust chain to that user.
My philosophy behind this is: Public private key encryption needs to be fully usable without the web of trust already being there - or else there will never be a chance for the web of trust to form in the size that is needed to actually make it work for everyone on this planet.
Here's the use case behind this: With a person who has never used GPG before, we created keys offline, exchanged them, imported them into the keychain and checked them (marked them as 'very strongly checked'). Then afterwards we weren't able to mail to each other without it looking like something is deeply wrong. Receiving mails shows something that looks like it didn't work, and sending didn't work at all (actually the same bug as #400).
On Tue 2015-02-03 03:24:58 -0500, Martin Häcker wrote:
This sounds like a problem to me, and this should not have happened.
What do you mean "marked them as 'very strongly checked'"?
Do you mean to say that you took the "Sign Key" action, and selected "I
have done very careful checking"?
If you did that, then enigmail should consider the user ID as valid, and
there should be no problem sending mail to the associated e-mail
address.
What does "looking like something is deeply wrong" mean exactly? is
there a specific error message that you can describe?
Thanks for reporting this problem.
Hello. My bug #400 was closed as a duplicate of this. I agree with the previous comment in that the Web of Trust can be an option to key validation, but it should not be a requirement. In addition to my statement in https://sourceforge.net/p/enigmail/bugs/400/#7991 that it should be possibe to send an email to a person even when their "calculated trusted" is not beyond a threshold.
I think that the modern crypto messengers are doing a much better job serving wide acceptance of cryptography. The idea of "Trust on First Use" with an option to verify/validate matches how people think and use crypto better. Enigmail alredy has an option to "Trust the keys of all recipients" in the New Message window, which goes into this direction.
That option should be available after you hit "Send" as well.
What we did
I believe this is usually the end point of the first discovery of gpg by new users - if they don't get stuck in any of the previous steps. At least thats my observation from helping new people get to use gpg on crypto parties (also when others explain it there) or spreading the use of gpg in my company.
From what I've read in this thread, this doesn't even seem to be a sensible way to use gpg - something that's new to me, and I'm a (casual) gpg user for at least some 10 years. :-(
Last edit: Martin Häcker 2015-02-03
On Tue 2015-02-03 10:47:10 -0500, Martin Häcker wrote:
Argh, i think you've been led astray by the user interface here. What
you've done (both with kleopatra and with enigmail) is to set the
ownertrust for a key. This has consequences you probably don't expect
(in particular, you're now willing to accept any identity certification
made by that key, which seems like you probably don't want), and as you
saw, just choosing "full" doesn't actually help gpg to accept the
validity of the key in the first place.
What the UI should have guided you to do is to "sign the key",
certifying it with your own key. That would make the User ID on the key
valid, without making any decision about whether you trust additional
external certifications made by that key.
argh, how frustrating. I know you're not the only one to get confused
by this. I've seen it with multiple people, of all skill ranges.
This confusion needs to be completely removed, but it's going to take
some time to sort it out.
The point is that you selected "Trust Certifications made by this Certificate." This refers to the signatures the key made on other keys (i.e. for building up the web of trust). This is not related to signing messages.
Even if we'd changed the language in Enigmail it would not have helped you, this just doesn't define how much you trust mails from this key...
Well, it does seem to help if it is set to 'ultimate'. Also the labels do not seem separate the different meanings of trust in gpg.
Also to get back to the original problem - I would have expected the label to tell me that there is some sort of trust on this key - but that it is not enough to qualify as 'green'.
Even better would be if there is then a link / explanation linked that describes possible reasons for the trust not being high enough and what to do to solve these.
"ultimate" is intended for own keys. In your case, I'd say it's a workaround because you didn't fully understand what you did and why the calculated trust results in what you got. I'm not blaming you for not knowing; I'm aware that this is damn difficult to get it right.
But you cannot blame Enigmail for something you misinterpret, because Kleopatra silently refused to what you expected from it...
Here's what I imagine could have helped to clear up this confusion:
Consider the UI showing two values separately: Validity and trustworthiness. Then if validity fails, the UI can lead the user into the workflow to actually get the key. This could be a button that launches a wizard, or some help page that explains it, or whatever. If on the other hand the trustworthiness of the key is too low (I imagine a progress-bar here, or traffic lights), the UI can lead me into the workflow to improve that trustworthiness. (Maybe I'm even fine with the trustworthiness of that signature being low) That workflow should contain the information what qualifies the trustworthiness of that signature and why it has so little trust right now. In this case: there is no chain of trusted signatures to that key. Then educating the user about how to build such a trust chain should be relatively easy.
What do you think about that? Does this miss some obvious use cases that are required for this UI?