Questions about trust signatures

[bezna]

Dear GnuPG users,

I have some questions regarding use of the tsign command; please don't feel
you have to answer all of them at once, just one will do, although I'd like
to point out that the one most important to me is #1. I’ve been doing some
reading and experimentation with tsign and I think I have a handle on how
the mechanics of it work. 

A brief aside: David Shaw posted a message
(http://lists.gnupg.org/pipermail/gnupg-users/2005-May/025612.html )
providing a link to an article which apparently explained trust signature
concepts well (
http://download.cryptoex.com/documents/whitepaper/cex2003-pgp-in-unternehmen-en/Tech%20White%20Paper%202002%20-%20Using%20OpenPGP%20in%20Corporations.pdf
). However, the link appears to be down and searches for the article have
turned up nothing. Does anyone (perhaps David himself) have a copy of it, or
know where I can obtain it? Thanks in advance; now, my questions:

1) My first question revolves around its application in a real-life
scenario. Suppose we have a strictly hierarchical environment, where the
validation of certificates depends solely on CAs. In such a scenario, would
the users perform trust signatures of a certain level on the CAs, who would
then perform trust signatures on CAs lower in the hierarchy (and thus lower
in power, since with each link in the trust signature chain the “trust
power” represented by the depth allotted to the tsig diminishes until it
reaches 1, the terminal value, beyond which the trust chain cannot be
extended through empowering other users with tsigs). Consider the following
example:

User 1 – tsig of depth 2 -->  Root CA – tsig of depth 1 --> Subordinate CA –
regular signature --> User 2

Thus, through this chain of trust, User 2’s certificate appears valid to
User 1. A similar chain could be traced from User 2 to User 1, or between
any other two users in the organization, using the Root CA as a hub for
trust signatures; alternatively, only the subordinate CA could be the
trusted entity by the users, in the case where that CA is responsible for a
department and users don’t care about the validity of all the certificates
of users outside their own branch in the organization.

So my first question is,  have I understood the use of this command in a
real-world environment correctly?  Are there other ways in which it could be
applied? Can it be applied in a non-hierarchical context? What I mean by
this is, is there some way to get rid of this “depth” functionality and to
be able to propagate trust continuously and indefinitely down a chain of
users, without having it diminish until it reaches an endpoint? For example
( --> denotes a signature, ==> denotes trust) :

A ==> B ==> C ==> D --> E

Through this chain of trust, Eve’s certificate appears valid to Alice. The
implementation of this example using GPG trust signatures would involve
using descending orders (the “depth” parameter) of trust signatures with
each hop:  

A =3=> B =2=> C =1=> D --> E

Obviously this “depth” parameter is better suited to the CA example outlined
earlier; it might not be possible for Alice (or any  other user in the
chain) to know how many hops away Eve is, and what depth to tsign Bob with
so that she will validate Eve’s certificate. Furthermore, if Bob tsigned
Carmen with a depth of 4 (for his own purposes), the chain of trust linking
Eve to Alice would be broken since GPG computes certificate validity (and
trust in the case of tsigns) only down paths where each next node in the
path was tsigned with a lower “depth” than the “depth” of the tsign on the
node before it. 

Is there some way to circumvent this in GPG, short of writing your own code?
Does the PGP Corporation’s program offer any alternatives?

That was the main question I wanted to address. Now, here are some other
issues I have with tsign:

2) I noticed that when two disjoint, continuous (not broken by a tsign
assigning only “marginal” trust somewhere) paths of tsigns of the same
length lead to the same certificate at the end of the path, the signature
which was last made is taken into computing that terminal certificate’s
trust rating, rather than some other criteria. This is hard to explain
without an example, so here it is:

  Root CA 1 --> CA 1 
 /                  \
A                    B --> C
 \                  /
  Root CA 2 --> CA 2 

Bob's certificate has been validated in two companies he works for. Alice
wishes to find the validity of Charlotte's certificate, who was signed by
Bob. She has tsigned the Root CAs of both companies (with a depth of 3 for
the sake of the example). Now, the subaltern CA (tsigned with a depth of 2)
of Company 1 has tsigned Bob (with a depth of 1) and specified that he was
fully trustworthy when it came to validating certificates. The subaltern CA
of Company 2 though, had also tsigned Bob but according to him Bob is only
marginally trustworthy. 

According to the current GPG implementation, CA2's signature which is the
most recent would be used in determining Bob's ownertrust in Alice's trust
database! Consequently Charlotte's certificate would appear marginally
valid. This to me seems flawed. If CA1's signature was made before CA2's
(assume CA1 is a procrastinator), then Bob would appear as fully trustworthy
to Alice and Charlotte would be validated. The fact that Bob's
trustworthyness to Alice hinges on which CA got his signature in last seems
like a bad approach to me.

3) What's the point of masking any depth of a tsign greater than 9 with a T?
>From what I've seen, a level 11 signature is still different from a level 12
signature and so on. Signatures beyond the threshold of 9 aren't discretized
into the same class.

4) What do the "12x" and "13x" mean in the following --with-colones
--list-sigs output? 

sig:::17:2E62D2D5026D69FA:2008-06-11::6 120::David:13x:

sig:::17:1816F82A9DE5372F:2008-06-11::1 60::Larry:12x:

5) As in question 2, I noticed that if there are two disjoint paths of
tsigns that lead to the same certificate and one path is shorter (suppose
Root CA 2 signed Bob's certificate directly), the shorter path is preferred
over the longer one. Are there any other rules for determining which path of
tsigns is used, using criteria such as the level of certitude in the
signature (3 for "checked very carefully", 2 for "checked casually", or 1
[or 0]), the depth of the signature, and so on? The only other "rule" I
seemed to find was the one mentioned in question 2, with the newest trust
signature winning over the older ones.  

That's all for now. Thanks for reading. Please note that Question 1 is my
priority, so please don't feel you have to answer all the questions or all
of them at once.

Thank you,

George
-- 
View this message in context: http://www.nabble.com/Questions-about-trust-signatures-tp17789248p17789248.html
Sent from the GnuPG - User mailing list archive at Nabble.com.