Michael Nahrath
Tue Dec 10 14:58:02 2002

Hash: SHA1

David Pic=F3n =C1lvarez <> schrieb am 2002-12-10 12:28
> First of all, thanks very much for the detailed reply, since you have jus=
> shown me that I don't understand the WoT, =A1when I thought I did! :-)

I only hope, that _I_ am not telling nonsense ...
>> Imagine you set ownertrust for key 0x5B0358A2 <> now.
> Yep, in fact I've done that.
>> Currently that won't change anything.
> It may let me validate keys signed by wk, I guess.

It woun't change their validity at all as long as wk's key has no validity
in your keyring.
>> But imagine that next week you had an occation to meet with Josh Huber
>> (just as an example) and sign his key 0x6B21489A.
> Ja. I doubt it very much, but I understand where you're going.

Maybe one from <> would have been
more likely but as they are not so active on this list I didn't have their
keys in my keyring.
>> Suddenly WK's key will be valid in your keyring and all keys it has sign=
>> will inherit calculated trust. All because Josh has signed Werner.
> Now here's where I get utterly and absolutely lost. Can you explain what =
> mean by this? If I say I trust WK and I trust JH, that just means, IMO, t=
> they can give validity (but not trust) to other keys. Otherwise can you t=
> me away from my error?

> Again, I need some further explanation, I think.

Best thing is you try it out on your own:

Get the keys 0x78F5E034 (Clemens, someone you shurely don't know)
and 0x9A4C704C (my key)!

gpg --edit-key 0x78F5E034   should print
pub  1024D/78F5E034  created: 2001-11-03 expires: never      trust: -/-

gpg --edit-key 0x9A4C704C   should print
pub  1024D/9A4C704C  created: 2001-11-02 expires: never      trust: -/-

Now raise the ownertrust of my key to
pub  1024D/9A4C704C  created: 2001-11-02 expires: never      trust: f/-

[!! this is the point of ownertrusting an unvalidated key !!]

check the other one, it is still
pub  1024D/78F5E034  created: 2001-11-03 expires: never      trust: -/-

[ Because my key is still invalid it can not pass anything to another key=A0]

Now get one more key (ct-magazine): gpg --recv-key 0xB3B2A12C

gpg --edit-key 0xB3B2A12C        Initialy it displays this:
pub  1024D/B3B2A12C  created: 1999-05-11 expires: never      trust: -/-

Now do 'lsign' and 'trust 4' to this key!
(Just for testing purpose. You may want to gpg --delete-key 0xB3B2A12C

Now check my key again!
It should be (without any further action taken by you!):
pub  1024D/9A4C704C  created: 2001-11-02 expires: never      trust: f/f

[ my key now got validity by the signature from 0xB3B2A12C AND the trust
you gave it before ]

Now check the 0x78F5E034!
It has changed to=20
pub  1024D/78F5E034  created: 2001-11-03 expires: never      trust: -/f

Suddenly you "fully trust this key" (in the words of GPG), just because it
is signed by me AND you ownertrust me AND my key is signed by some other
key that has ownertrust given by you AND is valid.

That is how ownertrusting an unvalidated key may have an effect.

I'll try to write up the logic in your keyring in some boolean style:

REL: (MYSELF signed ct-magazin)
REL: (ct-magazine signed Michael)
REL: (Michael signed Clemens)

SET: (ownertrust_for ct-magazine =3D f)
SET: (ownertrust_for Michael =3D f)

(MYSELF signed ct-magazin) =3D> (computed-trust_for ct-magazine =3D f)

{(ownertrust_for ct-magazine =3D f) AND (computed-trust_for ct-magazine =3D f)
AND (ct-magazine signed Michael)} =3D> (computed-trust_for Michael =3D f)

{(ownertrust_for Michael =3D f) AND (computed-trust_for Michael =3D f) AND
(Michael signed Clemens)} =3D> (computed-trust_for Clemens =3D f)

Greeting, Michi
Version: GnuPG v1.3.1 (Darwin)