PGP GPG Web of Trust, Find Most Secure Path

Web of Trust explaination

http://zarb.org/~gc/html/pgppathfinder.html  (http://pgp.cs.uu.nl/)

Showing trust levels with "gpg":
gpg --with-colons --list-keys
The second field and the ninth field are the ones you want. The
second field contains the validity, and the ninth field contains the
trust setting. See doc/DETAILS from the GnuPG distribution for all the possible values there.

2. Field:  A letter describing the calculated trust. This is a single
     letter, but be prepared that additional information may follow
     in some future versions. (not used for secret keys)
  o = Unknown (this key is new to the system)
                i = The key is invalid (e.g. due to a missing self-signature)
  d = The key has been disabled
      (deprecated - use the 'D' in field 12 instead)
  r = The key has been revoked
  e = The key has expired
  - = Unknown trust (i.e. no value assigned)
  q = Undefined trust
             '-' and 'q' may safely be treated as the same
      value for most purposes
  n = Don't trust this key at all
  m = There is marginal trust in this key
  f = The key is fully trusted
  u = The key is ultimately trusted.  This often means
      that the secret key is available, but any key may
      be marked as ultimately trusted.
 9. Field:  Ownertrust (primary public keys only)
     This is a single letter, but be prepared that additional
     information may follow in some future versions.  For trust
     signatures with a regular expression, this is the regular
     expression value, quoted as in field 10.

$ gpg --with-colons --list-keys
tru::1:1304353633:1309537403:3:1:5
pub:-:4096:1:EEB79C73B8EC3AC9:2009-05-18:::-:Geoffrey Thomas ::escESC:
pub:e:2048:1:B576D161BD18CA24:2010-04-27:2010-08-25::-:MIT 6.033 sp2010 (Key for hands-on #6 - Crypto) <6.033-staff@mit.edu>::sc:
sub:e:2048:1:6AC6D22E0D016CE7:2010-04-27:2010-08-25:::::e:
pub:-:1024:17:882E0BAD0B72EB0F:2009-04-27:2012-01-20::-:Barack Hussein Obama (DOD) ::scaSCA:
pub:-:4096:1:4372CDFF95630310:2010-04-08:::-:Chris Post ::scESC:
uid:-::::2010-04-09::A5898B3ADF21B9261C6F342945D94F0392F4E1F8::Chris Post :
sub:-:4096:1:365783180773FB2D:2010-04-08::::::e:
pub:u:2048:1:304085A3F33AAB16:2011-05-02:2011-07-01::u:HaoQi Li ::scESC:
sub:u:2048:1:182358B0146708AD:2011-05-02:2011-07-01:::::e:

mean shortest distance, strong set

pathfinder, with graphs, Wotsap
pathfinder in gpgwww.c of onak, example: looking up path to

leaf of trust graphs

PGP trust statistics

We found a few sites that talked about people implementing pgp web of trust and even making a graphical display. How does PGP use the trust signature (shown below, from document of OpenPGP) and the trust level of PGP for the web of trust?

5.2.3.13. Trust signature

The trust amount is in a range from 0-255, interpreted such that
    values less than 120 indicate partial trust and values of 120 or
    greater indicate complete trust.  Implementations SHOULD emit values
    of 60 for partial trust and 120 for complete trust.

No, PGP doesn't use "trust level" linked in webs.

===
GPG tutorial

===

Our project is to figure out how much you can trust paths, and in turn, keys, in the web of trust. It has 2 parts, Reiter and Stubblebine wrote papers on these topics:

1. Finding paths. How to find paths. PathServer is a web-based service for authenticating PGP public keys, i.e., determining their owners. It works by enabling a user to find paths of certificates from a key she trusts to a key she wants to learn about. You can find out more about this by having a look at "Path independence for authentication in large-scale systems." (1997) and "Resilient Authentication Using Path Independence" (1998)
2. Evaluating the validity of paths based on the level of trust on the nodes. A metric of authentication is a procedure for evaluating the assurance one has in a name-to-key binding. That is, it tells you how sure you can be regarding the apparent owner of a key, given the information available to you and how much you trust the various entities that apparently contributed this information. In this work, we developed a number of principles for the design of metrics of authentication, demonstrated how several proposed metrics fall short of them, and described a new metric that we believe comes close to being an acceptable metric of authentication: "Authentication metric analysis and design" (1999) and "Toward acceptable metrics of authentication" (1997)