multiple trust signatures

[Imran Khan]

>
>
>
> > key A assign trust signature to key B with trust value (full) and
> trust depth(3).
> > key A assign trust signature to key C with trust value (marginal) and
> trust depth(2).
> > key B assign trust signature to key D with trust value ( full) and and
> trust depth(3)
> > key C assign trust signature to key D with trust value (marginal) and
> trust depth(2)
> >
> > and assume that key A is ultimately trusted key
>
> In this case, B's certification of D's key+UserID is sufficient on its
> own for the user to believe that D's key belongs to D's User ID.  (this
> is a question of *calculated validity*.)
>


> This is because A's tsig on B implies a delegated full ownertrust of
> depth >= 1.
>
> So much for calculated validity.  Let's move on to ownertrust.
>
> Directly-assigned (i.e. not via tsigs) full ownertrust is always
> implicitly of depth 1.  That is, we're willing to accept certifications
> made by this party, but we're not willing to rely on chaining through
> their tsigs.
>
> > my understanding
> > and analysis is that if signatures for key D are read in the order of (B,
> > C), Key D's trust value and trust depth will be evaluated on the basis of
> > key C's (last read) signature and will be set to '0' for 'trust-depth'
> and
> >  'marginal' for 'trust-value'.Have I interpreted it correctly or am I
> > missing something?
>
> If this is the behavior you're seeing, it sounds like a bug to me.  From
> the above, i would expect gpg to treat D as having a trust depth of 2 at
> "full" -- this is because A's delegation to B of (full, depth 3) would
> drop one depth level, across B's full tsig on D.
>
> so the path through B is (full,3)_(full,3) → (full,2)
>
> and the path through C is (marginal,2)_(marginal,2) → (marginal,1)
>
> Combining the two paths should leave us with the strongest trust: (full,2).
>
> For a single trust path, i'd expect the chaining rule to be:
>
> if you start with:
>  (level_n,depth_n) on X
>
> and encounter the next-hop tsig (from X to Y) of (level_m,depth_m), it
> seems like the trust value for Y should be:
>
>  (min(level_m,level_n), min((depth_n-1),depth_m))
>
> But if you have multiple independent trust paths to Y, the general
> merging case is unclear to me.  And with non-independent trust paths to
> Y (i.e. where some paths share more than one node), the merging case is
> even more unclear.
>
> I would think that if any one path resulted in a depth no less than
> other, and with a higher trust level, the trust values from that path
> should be chosen.
>
> > Also can someone please answer whether trust signatures are made on the
> key
> > or (key,id) pair?
>
> trust signatures are made over the key+userid pair.  i touched on this
> briefly earlier in the year in my post to gnupg-devel titled: "WoT
> Proposal: double-counting suppression":
>
>  http://lists.gnupg.org/pipermail/gnupg-devel/2010-May/025586.html
>
> You might also be interested in the spec for trust signatures:
>
>  https://tools.ietf.org/html/rfc4880#section-5.2.3.13
>
> hope this is helpful,
>
>        --dkg
>
>

Thank you very much for your detail reply but unfortunately it got complex
:)

Well, let me rephrase, In its simplest form GPG code says that browse all
signatures on the (key, id) pair, and if it encounter a trust signature, get
trust value from it ,and set it for the current key(not uid), and set
trust-depth of the key to 'trust_depth -1' ( in GPG code this is stated in
validate_one_keyblock( ) function
as: pk->trust_value=sig->trust_value; pk->trust_depth=depth-1;)

Now my understanding is that this code, during a validation of
keyblock, replace trust-depth and trust-value for the current key(pk) with
the values from latest trust signature encountered every time, either on the
same or different id of the key (pk). This definitely lead to
some erroneous assignments of values, or I must be missing something causing
me a confusion.

you mentioned some metrics, like  (min(level_m,level_n),
min((depth_n-1),depth_m)) and in other place u stated, "Combining the two
paths should leave us with the strongest trust". Are these your
own intuition or these things are mentioned in GPG code somewhere?


BR
Imran Khan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101220/29394012/attachment-0001.htm>