Don't say "valid" or "invalid" keys in the OpenPGP key assistant resolution screen
Categories
(MailNews Core :: Security: OpenPGP, defect)
Tracking
(Not tracked)
People
(Reporter: KaiE, Unassigned)
References
(Blocks 1 open bug)
Details
This is a reminder bug.
The current plan for bug bug 1627956 is to use terms "Valid Keys" and "Invalid Keys" in the key assistant resolution screen.
I think we must change those terms, because they are incorrect in that context.
All keys on that screen are not immediately ready to use. However, if we call a key "valid", then why does the user need to do anything with that key? If it's valid, why do we explicitly require the user to further "accept" it?
The reason is, the user must accept the key to be fully valid for our purposes.
My point is, the term "valid" sounds very final. Like, it's valid, you're done.
I suggest to use a term that is more vague. For example, we could use the term "Usable".
Similarly, the other section is labeled "Invalid Keys". This isn't ideal, because "invalid" also sounds very final.
However, the keys we're offering are not completely invalid. If we find an update with updated validity, we can use it. Or, if the user undos a previous decision to mark the key as rejected, we can use it.
I'd reserve the term "invalid keys" for keys that really cannot be used at all, like revoked keys.
My suggestion is to label the second section "Other keys". I think it's ok to be vague here.
If the first category is "Usable Keys", and the second is "Other Keys", it's clear that those other keys are not immediately usable (and that's all we need to say here).
Some questions came to my mind:
What are "our purposes" exactly? Maybe there should be list/matrix of that purposes, maybe in the Wiki? Or even a flow process chart?
I think a purpose would be to verify a signature with a revoked key that was used to create the signature before the key was revoked, so for the purpose of validation of the past signature it would be still usable and valid, no? (or does a revocation certificate contain a date, from that on the key should be considered as invalid, e.g. if one gets to know that the key was compromised long in the past? then the revoked key would only be usable before that date)
What key cannot be used at all? That could be a key that does not match the TB accepted technical specifications (e.g. bit length, algorithm etc.), so e.g. it cannot be imported at all in TB to be used.
Like I said above, I guess even a revoked key can be used to validate a past signature.
The same for expired keys.
Maybe a key could or more precisely shall not be used at all if the user defines it willingly as "rejected", meaning: I know that this key is forged, invalid and/or dangerous, or for other reasons, even if it looks usable I definitely never want to use it. Are there other cases of a key that cannot be used at all, while being technically accepted?
OK Bug 1627956 is about TOFU for sending mail in the composer. Of course a revoked key cannot be used to encrypt a to be sent mail.
|
||
Comment 3•3 years ago
|
||
Agreed! Your labels are better. Feel free to sneak these tiny changes in the prototype before the build :)
|
Reporter | |
Comment 4•3 years ago
|
||
I realize that the "valid/usable" category might be hidden, and ONLY the "invalid/other" label may be shown. I think that would be weird, so I did more thinking on a better, more precise label.
Here's another idea: "Usable" + "Problematic"
Nico said in a chat he agrees that would be better.
|
|
Reporter | |
Comment 5•3 years ago
|
||
The latest patches of bug 1627956 already fix this wording.
Description
•