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


== TODO: ==
Things to do after discussion and Feedback not integrated in this draft

* tofu conflict handling probably needs more thoughts. It would be good to think and list more
  thoughts how a false positive conflict can happen to have a more clear idea what to do in the Ui.
* The yellow checker does not work as a symbol.
* Level 5 is not part of the screenshots.

== 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. Key should
not be used for opportunistic encryption.

* Level 1 (Validity Marginal && Touf.validity < Key with enough history for basic trust):
This level means that 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 and don't make assumptions
about the senders identity. There may be some indication that the
sender demonstrated a willingness to use crypto mails, especially
if opportunistic encryption is disabled.

* Level 2 (Validity Marginal && ((Tofu.validity >= Key with enough history for basic trust && signfirst > 3 Days ago) || 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. Automatically this Level can only be reached through
WoT.

* Level 4 (Direct Trust): A key that is ultimately trusted has signed
this key. Either yourself or someone that is allowed to make that
e.g. your central "CA" style person you may have in an organisation.

=== Rationale ===

=== Won't many Levels hurt Usability? ===
The "automated user" that never fiddles with GnuPG will only see Level one and
Level two. With level one being nearly presented as an "Unsigned" mail the
"Basic Trust" will be the only level that is really visible.

For more advanced users and from a "Ui Language" point of view
only two levels would be too simplistic because we have
to distinguish still between just automatic Trust based on history.
and trust from Web of Trust or manual checks.

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 and offer that option e.g. from a details dialog. So that
a user can mark "Ok with this communication partner I want to be absolutely
sure that I'm always using the right key. So I manually verify the fingerprint.".

That's a *can* it should not be suggested that this needs to be done, but
it should be offered.

The additional Level's also give flexibility for Organisational Measures like:
You may only send restricted documents to Directly trusted keys.

=== Why the time delay for level 2? ===

The idea is to make it more expensive for an attacker to reach level 2 as we
then start to make claims about the attacker. An attack that is kept up
over some time is more difficult. Especially if it involves some external
factors, like a phishing website etc. that might be turned of.
It also gives others the chance to intervene if they detect an attack.

It also mitigates User Experience problems arising from the use of the
encryption count in GnuPG's calculation for basic history because if
you encrypt 20 drafts or 20 mails quickly to the same key it should not
become level 2 before you have seen a signature.

A concern is that using the time of the first signature verifcation before reaching level 2 make lead to bad user experience. E.g.: You look at the same message after three days. Now it's level 2, last time you looked it was level 1.

== 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 intended
  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. This should be checked on the senders
side.

The most problematic way for conflicts is probably if a user has just
created multiple keys on multiple devices then we currently run into
a conflict state on the receivers side.

=== Resolving conflicts on the senders side ===

A tofu aware ~G~U~I should (even when TOFU is disabled) check
when a secret key is used for signing if there are other secret keys with
the same uid available and they are not cross signed a GUI
should offer that option.

Similarly, if a signature is verified by a mua and there are secret
keys available with the same userid and they are not cross signed
this should be told to the user and offered to do if possible.

==== WKD Checks ====

A tofu aware ~G~U~I should check when signing or from time to time
if a different key is uploaded to a WKD for this userid and warn
in that case. This will also make a permanent man in the middle
attack by a mail service provider more expensive as it would
mean providing a different key to the attacked user then to
others.

=== Resolving conflicts on the receivers side ===
We will have to see in practice how often tofu conflicts happen and
if there are different means we can avoid them. For now the preferred
solution is the Conflict Dialog. An alternative approach for
discussion is the automated resolution.

==== Conflict Dialog ====

A dialog should be offered that asks
the user to check with the sender / call his IT Support 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.

==== Automated Resolution ====
A conflict could be automatically resolved by just using the new key.

* Set the old key to policy bad
* Set the new key to policy auto

This would be detectable in the interface for a user who cares about it
because it will no longer be shown that the sender is somewhat verified
and that there is no basic history yet. Meaning the sender is back to
level 1.

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

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