Closed Bug 1626683 Opened 6 months ago Closed 6 months ago

Initial OpenPGP key trust management (direct trust)


(MailNews Core :: Security: OpenPGP, enhancement)

Not set


(Not tracked)

Thunderbird 77.0


(Reporter: KaiE, Assigned: KaiE)


(Blocks 3 open bugs)



(7 files)

This patch introduces trust management for public keys.

The general idea is, don't use the web of trust, don't use keys automatically.
Instead, we user must decide which keys are acceptable.

Initially, any public key is treated as "undecided", which won't be used automatically.
A signature from a undecided key will be treated with the "questionable" state - we show a "letter with question mark".

If the user is willing to use a key, without verification, it can be marked as "unverified". Signatures from an unverified key are shown with the "good signature, unverified identity" icon.

If the user has verified the fingerprints, it can be marked as "verified". Signatures from an unverified key are shown with the "good signature, verified identity" icon.

(If the signature was made by one the user's personal keys, it is shown with the good signature icon, without an identity icon).

Finally, if the user decides to not use a specific key, for example, because it's known to be a fake key, or, because the sender was unable to revoke it but is no longer using it, the key can be marked as rejected. Signatures from a rejected key will be shown with the "bad signature" icon.

For sending an encrypted message, Thunderbird must be able to find a key that is either unverified or verified. Keys that are in the undecided or rejected state cannot be used.
We'll prefer a verified key, if both unverified and verified keys are available.

The key manager dialog has been changed to remove all functionality that we haven't yet implemented.

The key details dialog has been changed to immediately present the user with the relevant choice - how the user wishes to treat this key. (See screenshot)

Currently, this "key details dialog", which offers the user to make the "key acceptance decision" can be reached from the key manager dialog, open.
The idea is that in a future enhancement, we make it easier to reach this dialog for a given key.
For example, when viewing a signed message, we may make it easiy to view the signature details. And from the explanation about the signature status, it should be another click to open the key details dialog.

In other words, if you receive a signed email with a questionable signature status, you might click the status, and decide that you want to edit how you accept the key.

When composing a message, in a future enhancement step, we might show which recipients have keys, and which don't. From there we might also offer the user to reach the key acceptance decision.

Implementation comments:

  • I've renamed an existing flag from UNVERIFIED_SIGNATURE to UNCERTAIN_SIGNATURE, to avoid a confusion with the "unverified key" state.
  • There are already 32 status flags. The JS variables didn't accept the 33th bit flag, it was left out. So I introduced an additional extStatus attribute, and started the new EXT_SELF_IDENTITY flag from the first bit.
  • we remember the user's key acceptance decision in a new sqlite file. It remembers if the key for the given fingerprint was accepted. Also, it separately remembers which email addresses are associated to that decision, which is the set of addresses that were visible to the user at decision time. I think this is important, because the key owner might later add another email address to the key. With the current implementation, the accepted key won't be automatically used for the added address. This needs more thinking later.
  • I tested with a real world key that wasn't revoked, but rather all its user identities had been revoked. Some fail safety changes were made because of that scenario.
  • I explicitly added more console.debug() statements when exceptions are caught. I want to learn what's going wrong while we're developing.
  • for a message that was both encrypted and signed, the existing code to obtain the sender's email address from the window didn't work. That's why I added the fallback code to look at the most recent window.
  • the key manager window will no longer show entries for a photo ID
  • headings for sub entries in key manager were removed. Now, only real user IDs are entries. Only if a key has sub IDs a plus sign will be shown to the left of a key, that makes the display more tidy.
  • implemented the "certificates" tab in the key details dialog. Changed to show the signer's key id, not the fingerprint. To show the fingerprint, it's required to have the foreign key available. I think we should allow double clicking such an entry to open the details of the signer key, which will allow viewing the fingerprint. That's a TODO. Also, I've temporarily enabled listing all signatures - not just the ones for which we already have the signer key. Let's see what people think about it. I think not showing those signatures at all would be incorrect.
  • the concept of "owner trust" is absent for now. Whether we accept third party trust, and how to offer that in the UI, will be decided at a later time.


  • if we don't accepted keys for all message recipients, sending will fail. This still needs to be improved with more details, like, which key was missing. This will be improved when working on composer as a next step.
  • move some strings from xhtml to the properties file
Attached image key-manager.png
Blocks: 1627742

Pushed by
Initial OpenPGP key trust management. r=PatrickBrunschwig

Closed: 6 months ago
Resolution: --- → FIXED
Blocks: 1627956
Blocks: 1627973
Target Milestone: --- → Thunderbird 77.0
Duplicate of this bug: 1603788
You need to log in before you can comment on or make changes to this bug.