|
⇤ ← Revision 1 as of 2016-10-25 10:26:39
Size: 4440
Comment: Validity and key use and Display with tofu + pgp / easygpg
|
Size: 5862
Comment: Update after discussion
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| == Concept of "Verified Communication partner" (Signatures) == | == Trust Levels === * Level 0 (Validity Unkown): 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 trustpath 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 achive 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 additonal 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 == |
| Line 10: | Line 51: |
| * Is there additional information that the sender is really is the indended communication partner. | * Is there additional information that the sender is really is the indented communication partner. (Level 2 + Level 3) |
| Line 12: | Line 54: |
| This could be displayed as a green checker or a seal ribbon or something. It should be prominent and next to the signed content. |
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. |
| Line 18: | Line 61: |
| sender is not verified it should be displayed the same as an unsigned mail because | sender is not verified it should be displayed similar to an unsigned mail because |
| Line 20: | Line 63: |
| Communication partner. | 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. |
| Line 30: | Line 80: |
| === Definition of Sender === | == 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: |
| Line 32: | Line 87: |
| * 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. |
* 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) |
| Line 35: | Line 92: |
| === 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. |
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. |
| Line 51: | Line 102: |
| * This is a marginally valid key for the recpient and the first UserID matches | * This is a marginally valid key for the recpient and the first UserID that matches |
| Line 53: | Line 104: |
| key was obtained through a slightly authenticated source. | key was obtained through a slightly authenticated source (e.g. WKD). |
| Line 57: | Line 108: |
| For Marginal keys there should be a visible hint that the recipient's key | For Marginal trusted keys there should be a visible hint that the recipient's key |
| Line 64: | Line 115: |
They may indicate: |
|
| Line 66: | Line 119: |
| === 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 === |
== Auto Key Retrieve == |
| Line 83: | Line 123: |
| 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: {{http://files.intevation.de/users/aheinecke/gpgol_sigs/trusted.png}} A tofu verified sender: {{http://files.intevation.de/users/aheinecke/gpgol_sigs/tofu.png}} A marginal signature without enough history: {{http://files.intevation.de/users/aheinecke/gpgol_sigs/tofu-untrusted.png}} An invalid signature: {{http://files.intevation.de/users/aheinecke/gpgol_sigs/invalid.png}} An unsigned mail: {{http://files.intevation.de/users/aheinecke/gpgol_sigs/unsigned.png}} |
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) |
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.
Trust Levels
- Level 0 (Validity Unkown): 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 trustpath 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 achive 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 additonal 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 / Ulitimately valid key for the recipient.
- This is a marginally valid key for the recpient 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 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 because you have seen a signature it is very likely that the recipient can decrypt. (auto-key-retrieve in gnupg)