<<TableOfContents>>

= 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 ===

* Level 0 (Validity Unknown): With trust-model tofu+pgp this is only for Keys that were never used
before to verify a signature.

* Level 1 (Validity Marginal && (Signcount < 10)): We have
some confidence that the recipient actually can use the key as we have seen
at least one signature or we have a weak trust path over the WOT. It's OK to
use that Key for Opportunistic encryption but when receiving a signed message
we should only show in details that a message was signed.

* Level 2 (Validity Marginal && (Signcount >= 10 || Key retrieved through slightly authenticated
  source (e.g. WKD)): We have some basic confidence that the Sender is who he
  claims because we either have an established communication history or the source
  of the key (e.g. the mail provider) provided the key for this sender. This is
  the highest level you can achieve without user interaction.

* Level 3 (Validity Full): This is reached either through Web of Trust or
  if a user explicitly set the tofu Policy to "Good" for this key. High
  confidence.


=== Rationale ===
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:

* Is there additional information that the sender is really is the indented
  communication partner. (Level 2 + Level 3)

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:

* Use the new key from now on. (Policy auto on the new Key, Policy bad on the old key)
* Reject the new key (Policy bad on the new key, Policy auto on the old key)
* Accept both keys, if the user claims to have verified that both keys are good (Policy Good on both
  keys)

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:

* There is a Fully / Ultimately valid key for the recipient.
* This is a marginally valid key for the recipient and the first UserID that matches
the recipients mailbox has a signcount of at least **one**. Or the recipients
key was obtained through a slightly authenticated source (e.g. WKD).

=== 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:
* Very little confidence (marginal + signcount < 10)
* Basic confidence (marignal + signcount >= 10)

They may indicate:
* Good confidence (marginal + signcount >= 100)

== 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 ==

{{gpgol-no-key.png}}

No key was found. Level 0.

{{gpgol-tofu-first.png}}

The first signed message form someone else. Level 1.

{{gpgol-tofu-second.png}}

The second message. Level 1.

{{gpgol-tofu-basic.png}}

Basic trust! Level 2.

{{gpgol-tofu-fully.png}}

Full trust! Level 3.

{{gpgol-invalid-sig.png}}

Invalid sig. Level 0.

{{gpgol-conflict.png}}

Tofu conflict. User attention required.