multiple trust signatures

[Daniel Kahn Gillmor]

Hi Imran--

you're asking good questions, but your example might be more complicated
than you need it to be.  More interleaved below:

On 12/20/2010 12:58 PM, Imran Khan wrote:
> Can someone please guide me, if there are multiple trust
> signatures(tsign) with different trust values and trust depth on the same
> key k, what values (trust-value and trust-depth) are stored for the key k.

Note that there are two underlying questions involved here:  ownertrust
and calculated validity.

GnuPG internally assigns ownertrust to a *key* (that is, "how strongly
are we willing to rely on OpenPGP certifications made by this key?").

But validity is calculated over a User ID and its primary key (that is,
"How sure are we that this primary key (and consequently, all of its
properly-bound subkeys) belongs to the real-world entity referred to by
the User ID in question?").

With that in mind...

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101220/16d13a43/attachment.pgp>