trust problem

[Neil Williams]

On Friday 19 Dec 2003 12:59 pm, cecilia hana wrote:
> hello,
>
> im a Gnupg beginner, in Gnupg user guide i know how to
> use trust to validate keys.
> It has two conditions 1 and 2, i understand the first
> but i don't understand the second,
> following is the second condition:
>
> 2. the path of signed keys leading from K back to your
> own key is five steps or shorter.

The first is to do with the number of marginally trusted signatures and fully 
trusted signatures. I see the second as an arbitrary limit on just how far 
the first condition can be pushed. If a key has been signed by three people 
you marginally trust, it can be fully trusted but if those three people are 
already a long way down the chain from your key, it makes it less worth 
trusting the final key so there needs to be a limit.

> peter------->blake------->elena------->chloe------->alex------->simon------
>->K

Blake's key shows as fully trusted to Peter because Peter has signed it.
If Peter sets the user trust on Blake's key to full, then Elena's key shows as 
fully trusted. From there on, the trust wanes because the chain is too weak.

> above figure shows that peter signed blake and blake
> signed elena then on and on,
> if peter just fully trusts simon, i think K's key is

How would peter fully trust simon? There would have to be secondary signatures 
(and a secondary/tertiary path) involving other people outside the chain 
described. For GnuPG on Peter's machine to fully trust Simon's key, one of 
two things would need to happen:
1. Peter would need to sign Alex's or Simon's key. (At which point the whole 
discussion becomes pointless).
2. Simon's key must be already signed by other users whose keys are in your 
keyring and who have a second path back to your key. 

If Peter manually sets the trust on Alex's key to full, it still doesn't mean 
that GnuPG will fully trust the key - the user value only affects it if the 
user trusts it less than GnuPG would normally set. That's why there are two 
trust values, user and generated. A trust setting of f/m (user, full; 
generated, marginal) is still only a marginal to GnuPG. A trust setting of 
m/f, however, renders a key signed by the m/f key only marginally trusted 
even though GnuPG is capable of using a higher trust. (The user trust setting 
affects keys signed by that key, not the key itself - you are asked to 
specify how much you want to trust a key signed by this key but not with your 
own key).

Take a look at a real relationship:
http://webware.lysator.liu.se/jc/wotsap/?top=0x92082481&bottom=0x28BCB3E3&size=&arrowlen=&arrowang=&colors=
(If this gets mangled, got to:
http://www.lysator.liu.se/~jc/wotsap/
and enter
0x92082481
and
0x28BCB3E3

As it stands, just from the diagram, I cannot trust Adrian's key. However, 
there's more to the picture. Martin Krafft and Michael Banck become fully 
trusted keys because of other signatures (in my case Peter Palfrader's 
signature makes a difference) and therefore Adrian's key shows as fully 
trusted to me ONLY once I've imported Peter Palfrader's key and a few others 
involved in the secondary path. Setting strong keys like this to full trust 
enables Adrian's key to be fully trusted.

> valid, however K is beyond the range of five steps,
> can anyone tell me why and i want more clearly
> nderstanding
> about the second condition, thanks.

The difficulty arises because to keep it simple to explain we need to talk 
about straight chains but in reality trust is a web and those keys that are 
arranged in a straight chain with no branches/connections are neither 
representative nor particularly strong.

In real environments, Simon or Peter would have probably signed either Elena's 
key or Chloe's key or signed JohnDoe's key who has in turn signed both 
Elena's and Chloe's. Either way, it circumvents the 5 link rule.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20031219/b69245d2/attachment.bin