Mirrors
/
open-keychain
mirror of https://github.com/open-keychain/open-keychain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Destroyed Trust and Certification Model (markdown)

Dominik Schürmann 2015-08-10 10:14:34 +02:00
parent b4c670d44c
commit a1e46d72f1
1 changed files with 0 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
Trust-and-Certification-Model.md

@ -1,38 +0,0 @@
### Decrypt/Verify Cases
| v/d | Case | What/Where | Color | Explanation |
|--- |----- |---- |------ |------ |
| verify | No signature | in Toolbar | red | Not a real error, TODO: maybe overlay? |
| | master key expired | in Toolbar | red | In most cases: Passphrase or secret key lost, key expired after some time, no real attack in 99% of the cases|
| | master key revoked | overlay error | red | Secret key stolen, used on a compromised device |
| | Unknown master key | in Toolbar with Name and Lookup button | red | Maybe change to automatic download in most cases? Currently red, because without a key it says nothing and can be at worst revoked/wrong sig, etc. |
| | subkey expired | - | red | see master key expired |
| | subkey revoked | - | red | see master key revoked |
| | Insecure signature key crypto | - | - | TODO: implement! |
| | Invalid signature | overlay error | red | attack |
| | Unconfirmed key | - | orange | not confirmed yet |
| | Confirmed key | in Toolbar with name | green | awesome |
| dec | No encryption | in Toolbar | red | Not a real error, TODO: maybe overlay? |
| | master key expired | - | - | TODO: implement? |
| | master key revoked | - | - | TODO: implement? |
| | subkey key expired | - | - | TODO: implement? |
| | subkey key revoked | - | - | TODO: implement? |
| | Insecure dec key crypto | - | - | TODO: implement? |
| | encrypted | - | green | awesome |
### Key Confirmations
see https://github.com/open-keychain/open-keychain/blob/development/OpenKeychain/src/main/res/raw/help_certification.html
### Trust
* We do not support "trust signatures" because they are rarely used and complex to implement.
* There are currently no plans to switch to a more complex model (like ownertrust).
### Certification screen
* Selection of names only, emails are grouped under names
* Do not allow selection of keyserver, this only confuses users where to upload the key (keyservers are federated). If the user really needs a separate un-federated keyserver, she can set the keyserver using the preferences as the preferred one.
* Instead of upload key, talk of "synchronize key"
### Reasons
* Email verification is too difficult to implement in an automatic fashion (requires certifying the user ids separately and sending these pub keys to the email addresses, then receive all those keys and import them again.)
* Names as a reality anchor: By asking the user if the person you see/hear corresponds to the key you received you prevent injection of keys with names from other people.