Mailing List Archive: [gnupg] trustdb problems, con't

[gnupg] trustdb problems, con't

Jan 27, 1999, 4:36 AM

Post #1 of 5 (268 views)

I have already been talking about the fact that "validity" is a
concept which is defined on (pubkey, user-id) pairs. Gnupg
calculates "validity" as a function of the pubkey alone. This is
worse than just a user interface problem.

In collect_paths(), this is done by looping over all user ID records
on a key and counting the number of fully or marginally trusted
certificates. Note that this counting is done on a per-key basis,
not per user ID. [1]

To see why this is wrong, assume we have four marginally trusted
introducers named ca_1, ..., ca_4 and a user. Assume that this user
has e-mail addresses a_1 to a_4 and a public key p, and that ca_k
has certified the associatioin (p, a_k) for k = 1, ..., 4. Let
marginals_needed be set to the default value of 3.

With PGP, we get four IDs with marginal validity, and the key won't
be used as an "introducer" - which is safe [2]. With gnupg, we get
a key with four marginally trusted certificates which lead to full
validity of the key. It will be used as an introducer, just like a
key which has a fully certified user ID. This is obviously wrong.

tlr

[1] There is another issue here: I'm not sure whether fully trusted
signatures should be counted as marginals, too. Counting the
various signature types separately and checking if

full_count/full_needed + marginal_count/marginals_needed >= 1

may be better. Equivalent: full_count * marginals_needed +
marginal_count * full_needed >= marginals_needed * full_needed.

[2] Though debatable. One may wish to use the validity of a key
(which will be something like the maximum user ID validity) as
some kind of weight for the owner's trust. For a clean approach
to the web of trust, including recommendations, see Maurer's
paper "Modelling a public key infrastructure". (Thanks to gec
for telling me about it.) Note that OpenPGP [RFC2440] actually
defines recommendation packets. They are called "trust
signatures" there.

--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi! I'm Signature Virus 99! Copy me into your signature and join the fun!

Re: [gnupg] trustdb problems, con't [ In reply to ]

wk at isil

Jan 27, 1999, 6:35 AM

Post #2 of 5 (267 views)

Permalink

Thomas Roessler <roessler@guug.de> writes:

> With PGP, we get four IDs with marginal validity, and the key won't
> be used as an "introducer" - which is safe [2]. With gnupg, we get
> a key with four marginally trusted certificates which lead to full
> validity of the key. It will be used as an introducer, just like a

So you found a bug. The code should remove all duplicate signators of
a key and only evalutate one.

> full_count/full_needed + marginal_count/marginals_needed >= 1

Maybe. The TODO ays that this code must be tested much more.

> some kind of weight for the owner's trust. For a clean approach
> to the web of trust, including recommendations, see Maurer's
> paper "Modelling a public key infrastructure". (Thanks to gec

I know this paper and originally I intended to do this - I have not
yet found the time for it and so I think we should go with PGP
approach for a while.

Werner

Re: [gnupg] trustdb problems, con't [ In reply to ]

caronni at olymp

Jan 27, 1999, 7:47 AM

Post #3 of 5 (266 views)

Permalink

Re: [gnupg] trustdb problems, con't [ In reply to ]

roessler at guug

Jan 27, 1999, 7:58 AM

Post #4 of 5 (268 views)

Permalink

On 1999-01-27 06:47:46 -0800, Germano Caronni wrote:

> I fully agree with Thomas, but on an even more principal level. If
> you divert in your trust model from the standard PGP behaviour,
> then this should be clearly shown to the user. Otherwise he will
> handle your trust values as he handles PGP trust values -- which is
> not correct, as Thomas shows in his example.

Actually, there is one more problem with this. Users will have to
rely on trust parameters when selecting public keys, see mutt's key
selection menu for an example.

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.

tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi! I'm Signature Virus 99! Copy me into your signature and join the fun!

Re: [gnupg] trustdb problems, con't [ In reply to ]

D.M.Pick at qmw

Jan 28, 1999, 7:32 AM

Post #5 of 5 (267 views)

Permalink

> 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