[gnupg] trustdb problems, con't

Germano Caronni caronni@olymp.org
Wed Jan 27 14:47:46 CET 1999

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.
It certainly is a good idea to allow for *different* trust models, be 
it for experimentation or actual use, as long as you make clear the 
difference... I would be very curious to hear what the argumentation
to add trust values on user ID's on a key is. It does not seem obvious
to me that trust in a key has any actual meaning -- only trust in a user-id
<-> key binding has.

Friendly greetings,

	Germano Caronni

p.s. For different trust models, you might want to have a look at
M. K. Reiter, S. G. Stubbelbin, Towards Acceptable Metrics of Authentication,
Proc. of 1997 IEEE Symposium on Security and Privacy, May 1997.
For the first model, I can also send you code.

Thomas Roessler wrote:
> 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!

Do you know the Internet Oracle? Answers _all_ your questions! http://olymp.org
Germano Caronni       germano.caronni@sun.com          <** webpage homeless **>
PGP-Key-ID: 19970907        gec@acm.org        4F3884ED32CC5C4E38FC75B474E0523E

More information about the Gnupg-devel mailing list