max-cert-depth and "chains of trust" in GPG

[bezna]

Dear David and GPG users,

Thank you for your clarification and prompt reply. I still have some further
questions. 

1) On the output of the --check-trustdb command, there is a line for each
level of depth in the path of signatures similar to this:

gpg: depth: 3  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u

What does the "trust: 1-" entry stand for? I noticed that this "-1" entry
usually accompanies the last hop in the chain of signatures that has made a
signature to validate another key. Similarly, I've noticed that sometimes
"trust: 0-" appears. What does this mean?

2) I'm a bit confused about the tsign command. I tried setting up some test
cases in which there is a chain of tsigns of the form A-->B--C-->D-->E etc.,
each tsign having been answered with "full trust" and "level 10" at their
respective queries during the signing protocol. I was puzzled to find that
the same occurred as with "regular" signatures; only those certificates
which were signed by someone the owner placed trust in directly were
validated, but they were given no trust values (IE their trust was
"unknown"). The extra trust information encoded in the trust signature
seemed to be lost to GPG, with one exception: the certificates tsigned by
the owner himself. I noticed that as soon as those keys who the owner had
tsigned were imported, their trust was automatically set to the value given
in the tsign, rather than defaulting to "unknown" as with regular
signatures. This was not the case for tsigns made further down the line from
those who the owner had tsigned. Am I then to understand that trust in GPG
is not transferrable, and that assigning trust can only be done directly by
the owner and not delegated to others, even through tsigns? That is to say,
there's no way to place confidence in the trust calls made the users whom
your own trusted introducers trust, and thus have a propagation of trust
down a chain? I was under the impression that the tsign was useful in a
system which uses Certificate Authorities (CAs), but the mechanism behind
its use is unclear to me. Could you please provide some additional
clarification on how tsign is supposed to work in the grand scheme of
things?  And just how can another user "make a signature on your behalf"? 


3) Also on the topic of tsigns, I was wondering what the trust signature
levels represented, how they are useful and whether any value greater than
10 (enough to qualify for a 'T') is treated the same.

Many thanks,

George

David Shaw wrote:
> 
> On Fri, Jun 06, 2008 at 01:26:19PM -0700, bezna wrote:
> 
>> However, this does not happen in GPG. Because Alice does not have access
>> to
>> Bob's trust database (unless he exports it and gives it to her), she has
>> no
>> way of knowing who Bob trusts and to what extent. Thus, she can only rely
>> on
>> the signatures made by Bob himself to determine if a certificate is
>> valid,
>> but not Bob's trusted introducers because she has no idea who they are. 
>> 
>>           A--> B--> C--> D
>> Depth: 0      1     2      3
>> Valid:   y      y     y      ?
> 
> Correct.  This is because Alice does not necessarily agree with Bob.
> The trust decisions are personal, and while Bob might feel that
> Charlie is a good signer, Alice might not.
> 
>> A workaround to this problem is for Alice to fully trust Charlie (who
>> appears valid to her because of Bob's signature) as an introducer,
>> thereby
>> validating Dale's certificate through him. Note that Alice doesn't need
>> to
>> sign Dale's certificate herself to do this.
> 
> Yes.
> 
>> So for Alice to be able to validate a certificate through someone else's
>> signature, she has to personally trust that someone else; the trust can't
>> transfer through an intermediate. 
> 
> Yes.  The "classic" trust model requires personal trust.
> 
>> Ok, now, after all this, which I hope you understood, come the questions.
>> Am
>> I understanding this correctly?
> 
> Yes.
> 
>> What does the max-cert-depth parameter refer to? Is that the depth of the
>> "chain of signatures"? 
> 
> Yes.
> 
>> And lastly, how do all these sites and applications that trace a path
>> between your certificate and another person's certificate work? Based on
>> tracing signatures alone?
> 
> Just signatures.
> 
>> Is it possible to export your trust database to these servers so
>> they will aggregate it into one and take trust as well as signatures
>> into account in determining validity down a chain?
> 
> No.  As I noted above, the trust database is very dependent on the
> owner - or put another way, why should you believe my trust database
> is correct?
> 
>> Is there anything out there that incorporates real chains of trust of
>> some
>> substantial length?
> 
> Yes, there is.  There is a different method of signing that does
> basically what you are looking for here - try a "tsign" (for "trust
> signature").  A trust signature does the same thing as a regular
> signature, but also contains the trust information that would have
> been put in the database.  Essentially, it allows you to issue a
> signature that says "I verified the key belongs to her, and I also
> trust her to make signatures on my behalf".
> 
> See
> <http://lists.gnupg.org/pipermail/gnupg-users/2005-May/025612.html>
> for some examples on how to use it.
> 
> David
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 

-- 
View this message in context: http://www.nabble.com/max-cert-depth-and-%22chains-of-trust%22-in-GPG-tp17700504p17738960.html
Sent from the GnuPG - User mailing list archive at Nabble.com.