UI terminology for calculated validities
nico at josuttis.de
Tue Apr 22 12:25:04 CEST 2014
please allow me to raise an issue I'd like to have harmonized among all
web mail frontends using PGP and GPG.
The reason I ask is because I am currently adding a feature for
auto encryption to enigmail.
The question is which terminology shall we use IN FRONTENDS
if we use the web of trust and want to signal
which keys can be used and which not.
According to doc/DETAILS we have the following validity entries:
> o = Unknown (this key is new to the system)
> i = The key is invalid (e.g. due to a missing self-signature)
> d = The key has been disabled
> (deprecated - use the 'D' in field 12 instead)
> r = The key has been revoked
> e = The key has expired
> - = Unknown validity (i.e. no value assigned)
> q = Undefined validity
> '-' and 'q' may safely be treated as the same
> value for most purposes
> n = The key is valid
> m = The key is marginal valid.
> f = The key is fully valid
> u = The key is ultimately valid. This often means
> that the secret key is available, but any key may
> be marked as ultimately valid.
That means, a key is "valid" if it is not
disabled/expired/revoked and has no unknown validity.
But everything else is valid.
That raises first questions:
- What does 'n' exactly stand for
(seems to be "less than marginal valid")?
Is this accepted if trust-model is "always"?
- My understanding is that even with always
encrypted is not allowed if the validity is
Is this correct?
Then there is the question how to present this
to user-interfaces for non-expert(!) user.
Intuitively, people would assume the following terminology:
- a key is "valid" if it is not expired, revoked, or disabled.
- we should send emails if we "trust a key"
(i.e. a key is trusted if the calculated validity
is enough to send the email encrypted)
Now "trust" for a key (or the associated uid) might be a problem,
because we use the term "trust" usually for ownertrust only.
But do we?
Note that the terminology is even used in the GPG 2.0 manual:
> --trust-model always:
> Skip key validation and assume that used keys are always fully
So the next question is:
Is "trust a key" a valid term?
And if so, which of the calculated validity values fall under it?
If "trust a key" is fine I could describe the effect of trust-model
always as something like:
- "Always trust all keys (except disabled/expired/revoked)"
If you don't like the term "trust a key" what else intuitive terminology
do you suggest?
(note: ideally all mailer should use the same in their UI's)
Nicolai M. Josuttis
More information about the Gnupg-users