I have some suggestions to improve the key import process, which at present I am finding quite cumbersome.
For example, if a key is received by emai the process is currently:
1. Click 'Import Key'
2. Click 'Yes" to import the key
3. Click '(Details)'
4. Switch to the 'Structure' tab to check the key type and length (current best practice is to compare: algo, length, fingerprint and creation/expiry date)
5. Switch back to the 'Basic' tab
6. Click 'certify'
7. Select level of certification (e.g. 'I have done casual checking')
8. Click 'OK' on the certification window
9. Click 'Close' on the key details window
10. Click 'OK' on the key import window
So my suggestion is to make some changes to the key import window in order to reduce the number of steps. The window currently looks like this:
By adding all of the necessary details and options to that window, the key import process could be reduced to two or three clicks. For example:
The key signing section could be collapsed or greyed out by default so as to not overwhelm users with so many options.
One more suggestion: that window would be an excellent place for a big red warning about the importance of key verification.
And a final one: the 'Enigmail Security Info' screen which is displayed when clicking the 'envelope' logo at the top-right corner of an email would also be better if it showed full key details for verification purposes (user name/email, fingerprint, key type and length, creation date, expiry date).
This sounds real nice! (though I have lesser electronic relations than David ;o) A step towards a slightly more efficient day-to-day using of Enigmail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The changes are non-trivial but feasible. However, the general movement is more and more moving toward TOFU (trust on first use) instead of the web of trust.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, the signing part is secondary to the issue of being able to verify key details. As Enigmail works right now, it is necessary to sign keys to prevent the yellow warning that appears at the top every email. Or am I missing something? I don't see how it would be any easier to use Enigmail on a TOFU basis without going through the same 9-10 step process. Is there a quicker way to sign/trust a key?
I've tested this on a lot of users in my organsation... Due to the process of verifying key details being so convoluted, users simply ignore it. If the relevant details (fingerprint, key algorithm, key length, and creation/expiry dates) were shown at the beginning of the process, it would be far easier for them and they would be more likely to actually check them.
Last edit: David 2016-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TLDR: me too please! My users need the interface to automatically take them to the sign key question because they are casual users, not PGP enthusiasts, and are only peripherally aware of the WoT idea. Also beginner and advanced users could both do with an import process that lets them see what's happening when I update a key (e.g. compare expiry dates of current key and key to be imported).
I would very much like this feature for my organisation (I was about to write this request myself before I found this post).
I set up PGP for all our employees, and the users in my company can use enigmail's easy-to-use features, such as clicking the encrypt/sign/attach my public key icons on the compose window, but do not understand key trust.
At the moment they import a key and it seems done - it requires a good understanding of the web-of-trust for a user to follow up by digging out the "sign key" menu. This should come up automatically since all keys need a trust certification, or even without WoT, in any other paradigm all keys still need a trust decision of some sort.
A good user interface could explain web-of-trust with its design. A key import wizard could naturally explain the idea to a new user if it had these steps:
Import a kerying one key at a time
Show key info, like fingerprint and expiry date, before user's import-or-not decision
Show if the key differs from one already in the keyring (e.g. a new expiry date), before import-or-not decision
Ask the "certify key" question.
If now (or later) a key is set to "casually" or "carefully" checked, then automatically pop up the ownertrust question.
Even for myself, an advanced user, it is currently very difficult to see what has changed when I update a key I already have (e.g. an updated expiry date).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you and your users don't care about the WoT, why don't you simply switch to the "trust always" trust model? This would spare your users from a lot of (apparently) unnecessary work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A system where all keys in the keyring are automatically trusted might be OK, but it would still need an import dialog where they are invited to accept or reject the key.
Some of them are using Mailvelope, which has a "trust always" model afaik. That too has no dialog when a key is added though, so they cannot see the fingerprint until after they import it into the trusted list, and even then only if they go digging in the menu to look for it.
Whatever PGP system you use there always needs to be some sort of user assessment of whether they believe a key's identity or not, or there's no point.
IMO this is best done with an import dialog, though yes, there are many forms that it could take.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A system where all keys in the keyring are automatically trusted might be OK, but it would still need an import dialog where they are invited to accept or reject the key.
That's implemented today (i.e. available in the current version if Enigmail). We display a dialog with the relevant information about the key before the key is imported, and the user can accept or reject the import.
The option to trust all keys is available in the Enigmail preferences
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, well, I certainly didn't realise that there is an option to trust all keys.
The import dialog is there, but doesn't explain that import doesn't mean trust and you still need to sign (if WoT), or that import means trust (if trust all). So the user is either led to believe that a job is done when it isn't, or worse, committing to more than they realise.
If you import a public keyring with multiple keys on it, it in fact discourages you from checking the keys because there is no ability to choose to import only a subset (e.g. only those that you have checked / been able to check), and it also it doesn't show if some key+ID s you already have so need not be checked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you suggest that there should be an explaining text displayed in/above the key import dialog. Which text would have helped you? Please make a suggestion.
Same for the key import procedure: How would you think an optimum sequence would look like? Which accompanying/explaining texts would you supply?
Regarding reimporting already present keys: This does not harm. Nothing is overwritten. OpenPGP keyrings always add information, they never replace. This is the same behaviour as keyservers show.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I came here to write a request very much like David's original post. He focused on convenience but I've emphasized the GUI being explanatory. If we're just talking about text changes then:
At the moment, afaik, the import text simply reads:"Import the following keys? [<userid>, <keyid> for each key]</keyid></userid>: Yes/No", and then after import a pop-up with important key info and "details" buttons for the each key's details pop-up. yes, you can drill down from there to the signing menu, but "details" sounds like it will show information, not offer choices.
In a trust-all model (sorry though, I still cannot find this option so I cannot confirm its current functioning) IMO it would be better with text "Import the following key(s)? Warning: it is easy for anyone to write any name on a key. Make sure these keys really have the correct key IDs for these contacts, or the key might belong to an impersonator." and the dialog options could be "I trust all these keys, import them"/"I have not confirmed these keys, cancel". It would be better still if this was choosable for each key separately, perhaps like this (please excuse my obviously appalling GIMP skills):
If enigmail is set to use WoT then (if not implementing David's full suggestion), IMO it would be better with text "Import the following key(s)? This will not trust the keys - after importing you should mark the key as confirmed or unconfirmed using the key details menu". The key management menu could have the "key validity" column visible by default, to help with this.
I have some suggestions to improve the key import process, which at present I am finding quite cumbersome.
For example, if a key is received by emai the process is currently:
1. Click 'Import Key'
2. Click 'Yes" to import the key
3. Click '(Details)'
4. Switch to the 'Structure' tab to check the key type and length (current best practice is to compare: algo, length, fingerprint and creation/expiry date)
5. Switch back to the 'Basic' tab
6. Click 'certify'
7. Select level of certification (e.g. 'I have done casual checking')
8. Click 'OK' on the certification window
9. Click 'Close' on the key details window
10. Click 'OK' on the key import window
So my suggestion is to make some changes to the key import window in order to reduce the number of steps. The window currently looks like this:
By adding all of the necessary details and options to that window, the key import process could be reduced to two or three clicks. For example:
The key signing section could be collapsed or greyed out by default so as to not overwhelm users with so many options.
One more suggestion: that window would be an excellent place for a big red warning about the importance of key verification.
And a final one: the 'Enigmail Security Info' screen which is displayed when clicking the 'envelope' logo at the top-right corner of an email would also be better if it showed full key details for verification purposes (user name/email, fingerprint, key type and length, creation date, expiry date).
Last edit: David 2016-09-03
This sounds real nice! (though I have lesser electronic relations than David ;o) A step towards a slightly more efficient day-to-day using of Enigmail.
Bump.
Any comments from the developers on this? Would the changes be difficult? Any other thoughts?
The changes are non-trivial but feasible. However, the general movement is more and more moving toward TOFU (trust on first use) instead of the web of trust.
Thanks.
However, the signing part is secondary to the issue of being able to verify key details. As Enigmail works right now, it is necessary to sign keys to prevent the yellow warning that appears at the top every email. Or am I missing something? I don't see how it would be any easier to use Enigmail on a TOFU basis without going through the same 9-10 step process. Is there a quicker way to sign/trust a key?
I've tested this on a lot of users in my organsation... Due to the process of verifying key details being so convoluted, users simply ignore it. If the relevant details (fingerprint, key algorithm, key length, and creation/expiry dates) were shown at the beginning of the process, it would be far easier for them and they would be more likely to actually check them.
Last edit: David 2016-10-02
TLDR: me too please! My users need the interface to automatically take them to the sign key question because they are casual users, not PGP enthusiasts, and are only peripherally aware of the WoT idea. Also beginner and advanced users could both do with an import process that lets them see what's happening when I update a key (e.g. compare expiry dates of current key and key to be imported).
I would very much like this feature for my organisation (I was about to write this request myself before I found this post).
I set up PGP for all our employees, and the users in my company can use enigmail's easy-to-use features, such as clicking the encrypt/sign/attach my public key icons on the compose window, but do not understand key trust.
At the moment they import a key and it seems done - it requires a good understanding of the web-of-trust for a user to follow up by digging out the "sign key" menu. This should come up automatically since all keys need a trust certification, or even without WoT, in any other paradigm all keys still need a trust decision of some sort.
A good user interface could explain web-of-trust with its design. A key import wizard could naturally explain the idea to a new user if it had these steps:
Import a kerying one key at a time
Show key info, like fingerprint and expiry date, before user's import-or-not decision
Show if the key differs from one already in the keyring (e.g. a new expiry date), before import-or-not decision
Ask the "certify key" question.
If now (or later) a key is set to "casually" or "carefully" checked, then automatically pop up the ownertrust question.
Even for myself, an advanced user, it is currently very difficult to see what has changed when I update a key I already have (e.g. an updated expiry date).
If you and your users don't care about the WoT, why don't you simply switch to the "trust always" trust model? This would spare your users from a lot of (apparently) unnecessary work.
A system where all keys in the keyring are automatically trusted might be OK, but it would still need an import dialog where they are invited to accept or reject the key.
Some of them are using Mailvelope, which has a "trust always" model afaik. That too has no dialog when a key is added though, so they cannot see the fingerprint until after they import it into the trusted list, and even then only if they go digging in the menu to look for it.
Whatever PGP system you use there always needs to be some sort of user assessment of whether they believe a key's identity or not, or there's no point.
IMO this is best done with an import dialog, though yes, there are many forms that it could take.
That's implemented today (i.e. available in the current version if Enigmail). We display a dialog with the relevant information about the key before the key is imported, and the user can accept or reject the import.
The option to trust all keys is available in the Enigmail preferences
OK, well, I certainly didn't realise that there is an option to trust all keys.
The import dialog is there, but doesn't explain that import doesn't mean trust and you still need to sign (if WoT), or that import means trust (if trust all). So the user is either led to believe that a job is done when it isn't, or worse, committing to more than they realise.
If you import a public keyring with multiple keys on it, it in fact discourages you from checking the keys because there is no ability to choose to import only a subset (e.g. only those that you have checked / been able to check), and it also it doesn't show if some key+ID s you already have so need not be checked.
So you suggest that there should be an explaining text displayed in/above the key import dialog. Which text would have helped you? Please make a suggestion.
Same for the key import procedure: How would you think an optimum sequence would look like? Which accompanying/explaining texts would you supply?
Regarding reimporting already present keys: This does not harm. Nothing is overwritten. OpenPGP keyrings always add information, they never replace. This is the same behaviour as keyservers show.
Well, I came here to write a request very much like David's original post. He focused on convenience but I've emphasized the GUI being explanatory. If we're just talking about text changes then:
At the moment, afaik, the import text simply reads:"Import the following keys? [<userid>, <keyid> for each key]</keyid></userid>: Yes/No", and then after import a pop-up with important key info and "details" buttons for the each key's details pop-up. yes, you can drill down from there to the signing menu, but "details" sounds like it will show information, not offer choices.
In a trust-all model (sorry though, I still cannot find this option so I cannot confirm its current functioning) IMO it would be better with text "Import the following key(s)? Warning: it is easy for anyone to write any name on a key. Make sure these keys really have the correct key IDs for these contacts, or the key might belong to an impersonator." and the dialog options could be "I trust all these keys, import them"/"I have not confirmed these keys, cancel". It would be better still if this was choosable for each key separately, perhaps like this (please excuse my obviously appalling GIMP skills):
If enigmail is set to use WoT then (if not implementing David's full suggestion), IMO it would be better with text "Import the following key(s)? This will not trust the keys - after importing you should mark the key as confirmed or unconfirmed using the key details menu". The key management menu could have the "key validity" column visible by default, to help with this.
What do you think?