> > > > > 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
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
