Questions about trust signatures

[David Shaw]

On Wed, Jun 11, 2008 at 04:10:28PM -0700, bezna wrote:
> 
> 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:

Internet Archive has it:

http://web.archive.org/web/20050315031244/http://download.cryptoex.com/documents/whitepaper/cex2003-pgp-in-unternehmen-en/Tech+White+Paper+2002+-+Using+OpenPGP+in+Corporations.pdf

You might also look around in the PGP.com white paper library for
similar information.  The PGP company bought the Cryptoex company a
while back, so PGP may have migrated some of the white papers over to
their own site.

> 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?

Yes, you have.

> 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

No.  The problem here is the use of the word "indefinitely".  Without
the depth concept, anyone in the chain can make a signature beyond
their "signing privilege" (for lack of a better term).  For example,
using the chain above, let's say that Alice is the regular user, Baker
is the company-wide Root CA, Charlie is a VP, and Dorothy is a
Manager, who manages Eve.  Note now in the example you give above,
Dorothy cannot issue a trust signature to Eve - just a regular
signature.  If there was no depth limiting it, Dorothy could go rogue
and issue a trust signature to an attacker who could then issue more
trust signatures, etc.  The depth (along with the domain restriction)
prevents people from further down in the chain from doing things that
you, the head of the chain, (Alice in this example) don't want to
accept.

To be clear, note that nothing stops Dorothy from issuing such a
signature.  It's just that when resolving the chain **from the
perspective of Alice**, Dorothy's signatures are limited to a single
hop.  Even if she issues a signature with a depth of 99, when looked
at as part of the chain above, the depth will appear to be 1.  When
looked at from the perspective of someone else, the results may be
different.

> 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.

Another way for Alice to handle the problem is rather than signing it,
simply to mark the CA key as "ultimately trusted".  This avoids Alice
having to know the depth of the chain, as it will cause any signature
by the CA to be treated as if it was issued by Alice herself.  This
can be thought of as a infinite-depth trust signature if you like.

> 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.

The chain isn't broken, the depth at each step is just lowered to
match the perspective of the head of the chain (Alice in this case).
If Bob tsigns Carmen, then from Bob's perspective, that chain in the
link had a depth of 4.  Similarly, if Roger signs Bob's key with a
depth of 5, then we have a new chain from Roger's perspective where
the Bob->Carmen link also has a depth of 4.  If Roger signed Bob's key
with a depth of 4, then the Bob->Carmen link has a depth of 3 (as it
is lowered to match the maximum depth granted by Roger).  If Roger
signed Bob's key with a depth of 50, then the Bob->Carmen link has a
depth of 4 (as it can't be larger than what Bob granted).

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

Both GPG and PGP handle this essentially the same way.  You can always
run with an external trust model by disabling trust in GPG, and doing
the work externally, but it won't be compatible with the rest of the
world.

> 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.

All approaches here are bad approaches, as one can always come up with
an example where the answer you want contradicts the answer you want
from another example.  Most recent is at least consistent and
reliable.

> 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:

It says how much the signer verified the key before signing it.  It is
really a cosmetic difference since GPG mainly ignores those numbers.
See "--default-cert-level" in the manual for more.

> 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.

Shorter wins.  The reason for this is that a long chain is a fragile
chain: each additional link adds risk of someone doing something
untoward.

David