certificate chain depth (technical)

[David Shaw]

On Apr 25, 2009, at 6:27 PM, Raimar Sandner wrote:

> On Saturday 25 April 2009 18:27:44 Raimar Sandner wrote:
>> Hello,
>>
>> when gnupg trusts a key as a result of trustdb calculations, I would
>> like to know what the chain depth for the given key is.
> [snip]
>> As of now I can only think of gradually reducing max-cert-depth,
>> recalculating trustdb and see, if a given key stays fully trusted.
>> Is there a better way to determin the cert depth? If not, I think
>> this would be a nice feature to implement.
>
> So as the discussion tends to drift a bit off-topic (no offense), I  
> would like
> to dedicate this sub-thread to the technical question asked.
>
> Is there some way to determin the certificate depth? I regard it to  
> be useful
> information, maybe someone else does too. I suppose the value should  
> be
> present somewhere in the trustdb, just not accessible right now.

The trustdb actually doesn't store per-user ID depth values.  Rather,  
one of the many possible depths is stored for the key as a whole,  
which is fine for our purposes, but may not give you what you want  
here.  Take the case of A signs B(uid1), A signs C(uid1), and C signs  
B(uid2).  B is thus fully valid as per B(uid1) being signed.  But  
B(uid2) is also valid, and at one level of depth larger than B(uid1).   
B as a whole thus lives at both depth 0 and depth 1.  We store this as  
1, but I think you'd want it at 0.

You can see this in action, and perhaps give you the information you  
want, by doing:

   gpg -v -v --check-trustdb.

You will see (along with some other debug info), a bunch of records  
that look like this

0:1234567812345678:K::?::::
0:1234567812345678:U:::f:::user at example.com:
0:1234567812345678:U:::m:::user at example.net:

The first field is the depth.   0 means "signed by an ultimately  
trusted key", and 1 means one step beyond that, etc.
The second field is the key ID
The third field is K for keys and U for user IDs.  You're more  
interested in user IDs here.
The 6th field is the validity:

   q == undefined validity
   f == fully valid
   m == marginally valid

The 9th field is a piece of the user ID string.

You can see some keys appear at multiple depths if a particular user  
ID from that key becomes valid earlier than other user IDs on the key.

David