Crypto Design Thoughts
A received email can be in a lot of different states regarding crypto: It can be encrypted or not, and signed with different degrees of trust and correctness. There are three independent factors involved which are mostly independent:
- Encrypted: yes/no/error
- Signed: yes/no/error
- Signing-Key: unknown/mismatch/unverified/verified/expired/revoked/insecure
The general idea is to have the information on the sign/crypt status in a single icon, with information about the involved key displayed as three dots next to it.
It would be possible to display the encryption and signature states as two independent icons. However, this takes a lot of screen space and does not optimize for the (hopefully) most common case: The email is correctly signed or signed+encrypted. More than one icon also tends to be annoying to users who aren’t interested in crypto to begin with (but who should use it anyways!).
In the icon, three vertical dots next to the crypto state icon are used to convey the state of the involved key. Keys are filled with color or greyed out, and there may be zero to three filled dots starting from the bottom, which are also consistently colored. This makes a total of four states:
- All keys greyed out is a special state which means that keys are relevant to the operation in general, but there is no information to display yet. For instance, this happens in the compose dialog while no keys have been selected yet.
- A single red dot is an error with one or more of the keys involved in the operation, or not all keys are available. This is not necessarily a problem, e.g. if keys are not available for all recipients in opportunistic encryption mode. The nature of the error affects the state icon in all cases, and should be reflected there.
- Two orange dots means there are keys available for (or involved in) the operation, but not all of them are trusted.
- Three green dots means there are keys available for (or involved in) the operation, and all of them are trusted.
The state icon has four states:
- Disabled
- Crypto isn’t enabled. Usually has no dots, except if used as an indicator that crypto isn’t enabled in opportunistic mode.
- Sign-Only
- Data will be or is signed, but not encrypted. Always colored blue. Dots for this icon indicate the trust level of the key used for signing. For compose, has no dots.
- Encrypt
- Data will be or is encrypted. Implies signing. Color and dots indicate the trust level of the key to encrypt to, or of the key the message was signed by.
- Error
- Indicates any type of error. This covers technical errors, like a broken ipc connection to the crypto provider, as well as cryptographic errors, such as invalid signatures. See also attention seeking.
For some states, an attention seeking animation can be added to the crypto state icon. This is intended to gently interrupt the user’s flow, but must be used accordingly rarely. This is also used to indicate that a click on the icon will open a non-standard dialog, which will commonly be a user interaction used to solve the error.
- Crypto Provider Connection
- When the connection to the crypto provider cannot be established, or access is not yet granted. A click on the icon launches a dialog which allows the user to solve the issue.
- Suspicious Content
- When signed or encrypted data doesn’t check out for some reason (expired/revoked key, insecure algorithm, broken mdc, etc), and the content is not initially displayed. A click on the icon shows an explanation of the problem, providing an option to show the content despite the error.
- Signed by Confirmed Key
This is the simple positive case, and the one we optimize for: The e-mail is signed, and the key and userid which signed it has been confirmed.
- Signed by Entirely Unconfirmed Key
The e-mail is correctly signed, but by a key where no user id is confirmed yet.
- Signed by Partially Unconfirmed Key
The e-mail is correctly signed, by a key where some user id is confirmed, and the one in the From address exists as a user id but is not confirmed. This state can be solved by asking the user to confirm the newly encountered user id.
- Signed by Unavailable Key
The key used for signing is not available, and could not be fetched, so the signature data could not actually be verified. This situation can often be remedied by fetching the signing public key from keyservers.
- Signed by Mismatched key
The e-mail is correctly signed, but does not contain a user id which matches the From address.
- Signed by Expired/Revoked Key
The e-mail is correctly signed, but the key which did so has expired or is revoked.
This state should be clearly communicated to the user as a type of incorrect signature. However, this state also commonly occurs when reading old e-mail, so something like “archived” might be a good metaphor particularly for the expired key case.
- Signed by Insecure Key
The e-mail is correctly signed, but the key which did so is insecure, most commonly if it uses an outdated algorithm or small bit size. This state is very similar to an expired or revoked key, and can be treated the same.
- Invalid Signature
The signature did not check out, so this is an actual error state.
- MDC Failure
The Modification Detection packet of the encrypted data could not be verified, which means the data was tampered with.
Discouraged! (will deal with it later)
Trivial. Since encryption was not enabled in the first place, this is a grey struck-through lock, staying out of the user’s way.