-----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----- _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
