#683 Not trusted enough for encryption only

[Kwadronaut]

I have a keypair with the rather odd trustlevel of 'full' instead of ultimate. Enigmail tries to avoid the situation where people still use it for signing:
"The key kwadronaut kwadronaut@PROVIDER (key ID 0xBF074F905E70C888) is not trusted enough. Please set the trust level of your key to "ultimate" to use it for signing."

So I figured: let's encrypt only, no signing! Alas, the error message is identical. Can we get a s/signing/signing and encrypting?

[Daniel Kahn Gillmor]

Enigmail is saying that it prefers to only try to sign your outgoing messages with keys that are yours. And it assumes that if a key is marked with ultimate ownertrust, it is your key.

There are a few use cases where these assumptions aren't correct, and can cause bad things to happen, but none of those corner cases will be fixed with the s/signing/signing and encryption/ change you propose.

If you're sending encrypted, unsigned mail to someone else, that mail is encrypted to the other person's key. It might also encrypt to your own key (so you can read the messages in your Sent folder). but it should do that without any such prompt.

Do you have any keys whose trust level is set to ultimate?

[Kwadronaut]

I think you misunderstood my report. I'm not talking about the corner cases, they crossed my mind, but I didn't want to bring them up at all, they should go to another bug report if you want.

A works as expected:
0. create a key, don't trust it utlimately
1. send a signed mail to someone else.
2. get a warning "The key kwadronaut kwadronaut@PROVIDER (key ID 0xBF074F905E70C888) is not trusted enough. Please set the trust level of your key to "ultimate" to use it for signing."

B the warning message is incorrect:
0. create a key, don't trust it utlimately
1. send an encrypted, unsigned mail to someone else.
2. get a warning "The key kwadronaut kwadronaut@PROVIDER (key ID 0xBF074F905E70C888) is not trusted enough. Please set the trust level of your key to "ultimate" to use it for signing."
But I deliberately switched off signing. Which keys to trust to encrypt to is a very lengthy discussion. I think that this warning shouldn't appear at all, but didn't do my homework in checking what presumptions Enigmail has about which keys it's fine with to encrypt to.

The flaw in the code is simple, both getEncryptionValidity: and getSigningValidity: use the same user interface string: retVal.reason = EnigmailLocale.getString("keyRing.keyNotTrusted", [this.userId, "0x" + this.keyId]); but they should be different.

And yes, I have a bunch of keys whose trust level is set to ultimate as well. Not sure how that question is related to this bug?

[Ludwig Hügelschäfer]

There's no question that your own keys should have set Ownertrust to "Ultimate". Everything else is just a misconfiguration. The next version of Enigmail will have an automatic check for this.

Your own key is not recognised as "valid" by GnuPG if the ownertrust is less than "ultimate". So if it is on the recipient list (e.g. by "encrypt to self") and you have "manual encryption settings" active and "To send encrypted, accept" is set to "Only trusted keys", then encryption fails because not all recpient keys are valid.

So far all is correct, except the error message. I'll prepare a patch to correct this.

[Daniel Kahn Gillmor]

On Wed 2017-04-26 20:14:15 +0000, Ludwig Hügelschäfer wrote:

There's no question that your own keys should have set Ownertrust to
"Ultimate". Everything else is just a misconfiguration.

While this is often the case, it's not always true.

For example, i might hold a shared key with a group of people (e.g. for
answering e-mails that arrive at a collectively-run helpline).

There is a good reason for me to not want to set the ownertrust on
that key to "ultimate" -- the key is held by multiple people, and any
one of them could have their machine compromised. setting it to
"ultimate" means that if such a compromise happens, GnuPG will be
willing to accept arbitrary identity assertions from the key (issued by
the attacker in this case).

So i'm not saying that enigmail needs to cater to this use case -- most
people don't operate collectively-staffed OpenPGP-based e-mail
helpdesks, and maybe those that do shouldn't be using thunderbird and
enigmail to do it. But please don't consider this legitimate
configuration a "misconfiguration".

    --dkg

[Ludwig Hügelschäfer]

Right. Sometimes I'm stuck in the Enigmail-single-private-user perspective. Thanks for pointing this out :-)

[Patrick Brunschwig]

This has been addressed long ago. Enigmail will display a warning if the trust level is not "full" or "ultimate".