Validity and Opportunistic encryption

This page is intended as a discussion base for validity display and opportunistic mail encryption when using the trust-model tofu+pgp.

Trust Levels


Originally the idea was to just have three states "Verified Sender", "Unverified Sender" and "Key is good enough for opportunistic Encryption".

After discussions about that this was too simplistic because we have to distinguish still between "I have manually checked this key" and just automatic Trust based on history.

Without a manual check we can never fully claim that the senders identity was verified. So with need an additional level for manually checked keys.

Why is Encrypt count not used ?

Encryption does not imply communication. You can easily encrypt 10 files or mails to a key and have no idea if the recipient can actually decrypt them. In contrast the signcount shows that the sender has signed with this key and you have verified so a communication has happened involving this key.

Signature Status

There should only be one prominent information when reading a signed mail:

This could be displayed as a checker or a seal ribbon or something. It should be prominent and next to the signed content. There should be a distinction between Levels two and three but it may be slight.

Don't treat signed mails worse then an unsigned mail

A MUA should not treat any signed mail worse then an unsigned mail. If a sender is not verified it should be displayed similar to an unsigned mail because in both cases you have no information that the Sender is actually your intended Communication partner. You may want to show a tofu Conflict more prominent as user interaction is required at this point.

Especially: ignore GPGME's Red suggestion An attacker would have removed the signature instead of invalidating it. It should be treated like an unsigned mail and only additional info in details should be shown for diagnostic purposes. Similarly when Red is set because a key is expired or so. It's not more negative then a unsigned mail.

Put it in Details

The information that a Mail was signed should of course be available even if the signature could not be used to verify the sender. And the user should get tips how to verify the sender (e.g. exchange fingerprints out of Band) but this should be "Details". Although easily accessible this should not be needed to establish cryptographically secured communication.

Conflict handling

A tofu conflict means that you have seen two keys for a userid and that the keys are not cross-signed and both are valid. Still in most cases this will be a false positive because someone has multiple keys and made the usage error not to cross-sign them. A dialog should be offered that asks the user to check with the sender and then:

Accepting both keys will change the validity from Marginal to Full. This is intentional because the question / option should be phrased in a way that a user did a manual check in that case.

Opportunistic Encryption (Mail only)

A MUA should offer automated opportunistic encryption. To determine if a mail can be sent encrypted one of the following rules must match for each recipient:

Marginal Substates

For Marginal trusted keys there should be a visible hint that the recipient's key might not be the intended recipient. E.g. a Lock symbol with different overlays for warning, yellow checker, green checker.

These substates should indicate:

They may indicate:

Auto Key Retrieve

If you receive a message from an Unknown Key a MUA should automatically retrieve it from a public keyserver or a Web Key directory. This Key can then be used for opportunistic encryption because you have seen a signature it is very likely that the recipient can decrypt. (auto-key-retrieve in gnupg)

Screenshots from GpgOL


No key was found. Level 0.


The first signed message form someone else. Level 1.


The second message. Level 1.


Basic trust! Level 2.


Full trust! Level 3.


Invalid sig. Level 0.


Tofu conflict. User attention required.

AutomatedEncryption (last edited 2016-12-01 14:40:24 by AndreHeinecke)