UI terminology for calculated validities

[Gabriel Niebler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> A key on my keyring is "valid" if it is not expired or revoked. 
>> It is "authentic" if it bears one signature from one of my keys,
>> or several signatures from other keys to which I have granted
>> marginal authority to authenticate keys. """
> 
> I can see that "authenticity" is in some ways more appealing as a
> term than "validity".

Thank you. That was the whole point, really.


> But i agree with Peter that trying to redefine "validity" to then
> mean something else is likely to be asking for trouble, given the
> existing established terminology.

You and Peter are quite right and thanks for pointing this out. Having
a word, with an established meaning in GnuPG, and then suddenly
changing its meaning would cause far more confusion than its worth.

If one were to rename "validity" to "authenticity", then from that
point on, the word "validity" should not be used anymore, at all, in
the context of OpenPGP keys (or certificates, as I should probably
say). That's a shame, as "validity" is a good word with useful
connotations for some things, but it couldn't be helped.

> I also wonder what term you would propose using as the opposite of
> "authentic".  "valid" can be opposed cleanly with "invalid".  Would
> you say "inauthentic" or "unauthenticated"?  I prefer the latter
> term, but in that case, perhaps the positive version should be
> "authenticated" rather than "authentic".

Hmm, well as far as GPG is concerned, the question does not really
come up, because it shows the "validity"/"authenticity" _levels_ and
the words for those (ultimate, full, marginal, unknown) don't need to
be changed.

But this discussion is mainly about other UIs and it's relevant there.

I agree that 'inauthentic', the natural opposite of 'authentic', is
saying too much. The software doesn't know whether the given ID is
authentic or not, so it shouldn't pretend to know that it isn't.

I came up with the following pairs of (functional) antonyms:
1) 'authentic' - 'unknown'
2) 'authentic' - 'possibly fake'
3) 'authenticated' - 'unauthenticated'
4) 'authenticated' - 'not authenticated'
... or one can adopt the GnuPG CLI convention:
5) 'authenticity': 'unknown'/'marginal'/'full'/'ultimate'

And some other suggestions were made, too:

6) 'verified' - 'unverified'
7) 'verified' - 'not verified'
8) 'verification': 'unknown'/'marginal'/'full'/'ultimate'
9) 'accepted' - 'not accepted'
10) 'usable' - 'unusable'
11) 'usable' - 'not usable'

There may have been others I'm forgetting.

> Also, i think it is a problem to say a key is valid or authentic.
> It is not the key that is valid or authentic, it is the combination
> of the key and a given user ID.

Ah, yes ... you're right, of course. I glossed over that, since I
believe that most certificates simply consist of a master signing key
(an encryption subkey, which we can ignore here) and one UserID. But
there may be other UserIDs and - for that matter - different
certificates with the same UserID and the question is always only "Is
this UserID valid/authentic/verified/usable/accepted/whatever with
this key?". It's good to state this clearly here.

> An OpenPGP certificate as a whole contains one master key and one
> or more User IDs.  So the certificate itself may contain some 
> valid/authentic <key,userid> combinations, and some 
> invalid/unauthenticated <key,userid> combinations.
> 
> In some scenarios, you want to talk about the certificate as a
> whole, and sometimes people want to make assertions about the
> validity or authenticity of the certificate itself, even though it
> may be in this mixed state.  For example, when a user applies
> ownertrust to a given certification-capable master key, GnuPG still
> only relies on certifications made by that key if the certificate
> containing the key has at least one valid <key,userid> combination.
> So in some sense, GnuPG considers a certificate as a whole (and by
> implication, its primary key) as though it it has a validity by
> taking the maximum of the validity of all of the certificate's user
> IDs.
> 
> I'm not proposing that we expose this detail to the end user,
> though, just laying out to the detail-oriented people on this list
> so that we have a common understanding.

GnuPG will also allow me to encrypt some text to (an encryption subkey
of) such a mixed-case certificate (I think), because it cannot
possibly know the intended recipient, so checking
validity/authenticity/... of that specific UserID is up to me. That's
as it should be, so also here, I can talk of the
validity/authenticity/... of the certificate as a whole.

Some higher level software, however,  may _know_ who I want to write
to and not allow me to use a given key, because
validity/authenticity/... of THAT UserID on THAT certificate with THAT
master key has not been established.

When that happens, such software should inform me of this in a way
that's helpful and as understandable as possible even to new users.
And it's at this point that the detail will have to exposed to the user.

I trust, though, that such mixed-case certifcates will be found very
rarely in people's public keyrings and almost never in those of new
users (after all, when signing a key, the signature is ausually
applied to all UserIDs by default), so I think it's perfectly
acceptable to hide a bit of the complexity by simply showing a
_certificate's_ validity/authenticity/... and to only go into details
when necessary.

Best
 gabe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXCyjAAoJEO7XEikU4kSzxh8H/jDgNa2F1kPzWKyqSEbayYsM
dSVLH7GPUsb934d9LGTj/xOlLpt2dhVSdtBpFCk0/Lt+NqLiu8yaBuA1A6H/bvgh
jOszkSyCffLb5pbNi9wGwY0u93COVa9Ob743NtTjkPNd0kJ6gnjXiOSDN7l1lIzv
R4ZRWU3w62HJOcj8Ul/0ujg7CqnS1dYr3ylQoqvHskQw45I+UQSw9hyUVg+hOQ19
Qgu+XyM9MSlSE35qHI7h71UDCj74uJpNN7R0FHMKpG6EybZ7qjoPrYdK0ueMYvGY
BkjW5qMcSbqNNpA9SpxzgsCJTyDEVKtDW+Fr7hosbT2rWDQu+KME2VyW77d4v0s=
=fuKk
-----END PGP SIGNATURE-----