[gnupg] trustdb problems, con't

David Pick D.M.Pick at qmw.ac.uk
Thu Jan 28 14:32:47 CET 1999


> With gpg's approach, the validity parameters for different user IDs
> are accumulated into validity parameter for the key, and then
> transferred into the user ID which is represented in the "pub:" line
> of gpg's key list.  This will lead to wrong conclusions about the
> validity of a particular (key, id) association.

Actually it's ever worse than that! What we *really* want is a
measure of how much we trust the total set of signatures on a key.
What is it we are "trusting"? It's the level of confidence we have
in the statement "this key belongs to the person refered to in the
specific user-id". And we sum the partial trust levels we ourselves
have assigned to each user-id that tells us how confident we are
that this person knows under which circumstances to sign a
key<->user-id pair. BUT individuals have may very well have more
than one user-id (perhaps with the same key, perhaps with different
keys). *We have no information about the relationship between
user-ids and real-world individuals.* So someone could quite
reasonable have several user-ids, sign a key<->user-id binding
for someone else *with each of their user-ids* and we might end
up totally trusting the resulting data on the basis of partially
trusting one individual! Of course, we *could* trust only one
of that persons user-ids, but then we'd have to hope they
always signed with that one or else we wouldn't be able to use
any signatures generated with any subset of the other keys they
have generated. In particular seperate DH and RSA keys. (I'm
outside the US so I can use RSA keys with gpg.)

It's a good clue if there are several user-ids attached to one
key that there may be one real-world individual behind them, but
if that individual has multiple keys we don't have any way of
informing gpg or pgp about the relationship(s). And making
sure the different keys for one individual are subkeys of
one main key can make such associations; but this is tricky
to manage and subkeys can't always be used for some operations
(easily).

Now, under these circumstances, I suspect we don't want to
start inventing new trust models without a *lot* more detailed
investigation of the consequences. But I think the safest thing
is to be fairly conservative and make sure we don't over-trust
the information we have.

-- 
	David Pick






More information about the Gnupg-devel mailing list