Validity and Opportunistc encryption
This page is intended as a discussion base for validity display and opportunistic mail encryption when using the trust-model tofu+pgp.
Concept of "Verified Communication partner" (Signatures)
There should only be one prominent information when reading a signed mail:
- Is there additional information that the sender is really is the indended communication partner.
This could be displayed as a green checker or a seal ribbon or something. It should be prominent and next to the signed content.
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 the same as an unsigned mail because in both cases you have no information that the Sender is actually your intended Communication partner.
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.
Definition of Sender
- Mail: The Sender is the first UID where the mailbox matches the mailbox of the From header.
- File: The Sender is the UID from the Signer's User ID subpacket of a signature.
Definition of Verified Sender
A sender is only verified if the signature was made by a key that contains a UID for the Sender and one of the conditions match:
- The signature is Fully / Ultimately valid.
- The signature is marginally valid and:
- The signcount shows that there were several signed messages exchanged involving this key. The current threshold for this is at least ten messages.
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:
- There is a Fully / Ulitimately valid key for the recipient.
- This is a marginally valid key for the recpient and the first UserID matches the recipients mailbox has a signcount of at least one. Or the recipients key was obtained through a slightly authenticated source.
Marginal Substates
For Marginal 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:
- Very little confidence (marginal + signcount < 10)
- Basic confidence (marignal + signcount >= 10)
- Good confidence (marginal + signcount >= 100)
Definition of slightly authenticated source
A slightly authenticated source is a key from a source that gives some confidence in the fact that a recipient controls the key obtained from the source.
It does not influence the status of Verified Sender more then seeing one signed message of that sender. The slightly authenticated source should just help determining an automatically selected key for opportunistic encryption that shows an indication that the recipient controls the key exactly as if you would have already seen one message signed with that key.
Keys from public keyservers
If you recieve 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.
Examples from GpgOL
The Information boxes in the screenshots only open when a user hovers over the Icon. A click on the Signature Icon should open a Key Details dialog with further information about a key and e.g. options for conflict handling.
A web of trust verified sender: 
A tofu verified sender: 
A marginal signature without enough history: 
An invalid signature: 
An unsigned mail: 