PGP - the Web of Trust


In mastering PGP there are several concepts that have to be mastered (this in addition to what are for may people extremely cryptic commands) - one of these concepts is the Web of Trust.

What is the Web of Trust?

Let's start from the beginning, which is always a good place to start. When you created your key the first thing that you did was that you signed your key (with PGP 2.6.3i this is automatic). You did sign your key didn't you? If not sure you'd better check. I've seen too many cases of people who have not signed their own key, often people who should have known better, often people who have their own PGP Web page.

The reason for signing your key is that it prevents key tampering.

Once the key has been signed the next step is to get at least one other person (or key holder) to sign your key. This extra signature provides a link to other keys. If you look at my key you will see that it has signatures from key(s) other than my own. Anyone who receives a key in person from myself is asked to sign my key. There are therefore keys radiating out from myself, each with possibly different signatures, but signatures of use for the path followed.

Let's assume that you have a key for a third party called Fred. You have not received your key in person from Fred, therefore you can't be sure with any degree of certainty that the key actually belongs to Fred, then you notice amongst a score of signatures one from myself. Assuming that you have a trustworthy copy of my key, then because you know I'm a reliable fellow and would never sign a key unless I was absolutely certain of its owner then by the very fact that Fred's key bears a signature from myself the key must belong to Fred.

As an important aside I'll raise another point. Never, never sign a key unless you are absolutely certain that the key belongs to its claimed owner. If in doubt do not sign as other people will be relying upon your judgement.

The Web of Trust consists of these fine filaments that radiate from and criss-cross every key. The signatures form the gossamer of the web of trust.

A few practical examples will illustrate the Web of Trust.

A Path from Phil Zimmermann to Ståle Schumacher

Ståle Schumacher heads up the International design team for the International version of PGP. He also runs a very good Web site for PGP.

Let us assume that you have downloaded a copy of the International version of PGP from Ståle, or possibly you have ordered it direct from myself. Within this package you will find a set of keys, including Ståle Schumacher, Phil Zimmermann and several other PGP luminaries. The whole package is signed with Ståle's key.

For the sake of argument let's assume that you have a genuine copy of Phil Zimmermann's key (or you may have seen Phil's key in a book and been happy that it has not been faked). Using Phil's key you want to be sure that you have Ståle's key as although you have downloaded the package from Ståle's Web server you can never be absolutely certain that either the server has not been attacked, or substitution has not taken place when downloading the key or the package.

First you will check whether or not Phil has signed Ståle's key. He hasn't. Now you have to try and establish a link between the two keys, that is you trace the filaments of the Web of Trust

Has Phil signed a key, who has signed a key ..... who has signed Ståle's key. This is tracing out the Web of Trust. Luckily those clever guys at the Death Star have set up a Web page that will do this for you. All they need is Phil's KeyID, Ståle's KeyID and after a very lengthy wait you will have drawn out before your very eyes the paths, including intervening keys, between the two keys.

To save you doing this I've combined the results of two such searches.

This is the text version. You can download a neatly traced map, or choose to download a key block containing all these keys. You could also obtain each individual key by other means and perform your own checks.

As you can see there are a number of paths between the keys. From three runs I got different results. There must be some random element, it also shows that these paths are only some of many. Also note the path through Betsi, which shows the possibility of several different routes.

C7A966DD says 9D997D47 => Peter Gutmann <pgut1@cs.aukuni.ac.nz>
9D997D47 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 67ECF13D => David A. Barnhart <CIS:70275,1360>
67ECF13D says 18239E91 => Robert C.Casas <73763.20@compuserve.com>
18239E91 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 4AAF00E5 => Dave Del Torto <ddt@lsd.com>
4AAF00E5 says DA87C0C7 => Edgar Swank <edgar@Garg.Campbell.CA.US>
DA87C0C7 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 32DD98D9 => Vesselin V. Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>
32DD98D9 says A770AE71 => John DeHaven <john.dehaven@wov.com>
A770AE71 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 4B2700B9 => Ross Anderson <rja14@cl.cam.ac.uk>
4B2700B9 says CE766B1F => Paul C. Leyland <pcl@ox.ac.uk>
CE766B1F says 23F5ADDB => Ian Jackson <iwj10@cus.cam.ac.uk>
23F5ADDB says 5BF376A5 => Grant W. Denkinson <G.W.Denkinson@geog.nott.ac.uk>
5BF376A5 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 7D63A5C5 => Hal Abelson <hal@mit.edu>
7D63A5C5 says 391C8DA5 => Matteo Frigo <athena@artemide.dei.unipd.it>
391C8DA5 says 69163909 => Matteo Frigo <athena@theory.lcs.mit.edu>
69163909 says 1B7A97ED => Patrick J. LoPresti <patl@lcs.mit.edu>
1B7A97ED says E1AED86F => John A. Perry <perry@jpunix.com>
E1AED86F says EFE9DDE7 => Mark Turner <markt@pipex.net>
EFE9DDE7 says D811F5C9 => Andrew C. Bray <andy@madhouse.demon.co.uk>
D811F5C9 says 0C9C1545 => Tim Morley <tim@derwent.co.uk>
0C9C1545 says 23F5ADDB => Ian Jackson <iwj10@cus.cam.ac.uk>
23F5ADDB says 5BF376A5 => Grant W. Denkinson <G.W.Denkinson@geog.nott.ac.uk>
5BF376A5 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 4D0C4EE1 => Jeffrey I. Schiller <jis@mit.edu>
4D0C4EE1 says A82FC877 => Paul S. Traina <pst@cisco.com>
A82FC877 says DF118AF1 => Havard Eidnes <Havard.Eidnes@runit.sintef.no>
DF118AF1 says BA95C0F1 => Harald Nordgard-Hansen <hhansen@kjemi.unit.no>
BA95C0F1 says 9BA46775 => Boerge Brunes <borge@cc.uit.no>
9BA46775 says 83C12FC1 => May Liss Haarstad <may@cc.uit.no>
83C12FC1 says 6AEB8375 => Boerge Brunes 301068 77638798
6AEB8375 says FEB0FBDB => Stale Schumacher <staalesc@ifi.uio.no>
FEB0FBDB says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says A07786A1 => Betsi <certify@bellcore.com>
A07786A1 says D5327CB9 => wietse venema <wietse@wzv.win.tue.nl>
D5327CB9 says 8E0A49D1 => Wolfgang Ley, DFN-CERT <ley@cert.dfn.de>
8E0A49D1 says 76EA7391 => Sascha 'Master' Lenz <master@wuerzburg.de>
76EA7391 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says A07786A1 => Betsi <certify@bellcore.com>
A07786A1 says D5327CB9 => wietse venema <wietse@wzv.win.tue.nl>
D5327CB9 says 4F570BA3 => Ingmar Camphausen <ingmar@aurora.in-berlin.de>
4F570BA3 says A9339109 => Thomas Lochner <thomas.lochner@tu-clausthal.de>
A9339109 says 4A27F015 => Jochen Hein <jochen.hein@informatik.tu-clausthal.de>
4A27F015 says 657BCAAD => Joerg Czeranski, 30 Oct 1970 Hannover, Germany
657BCAAD says 76EA7391 => Sascha 'Master' Lenz <master@wuerzburg.de>
76EA7391 says CCEF447D => Stale Schumacher <staalesc@ifi.uio.no>
C7A966DD says 8DE722D9 => Branko Lankester <branko@hacktic.nl>
8DE722D9 says F00F0421 => cert-nl.master-certification-key
F00F0421 says 53AAF259 => Klaus-Peter Kossakowski, DFN-CERT <kossakowski@cert.dfn.de>
53AAF259 says 28CBE7F5 => Felix von Leitner <leitner@prz.tu-berlin.de>
28CBE7F5 says AF7B30C1 => Ralf Baechle <linux@uni-koblenz.de>
AF7B30C1 says 01F9D1F1 => Chris Blum <chris@phil15.uni-sb.de>
01F9D1F1 says 593238E1 => Thomas Roessler <Thomas.Roessler@Sobolev.Rhein.DE>
593238E1 says F0841B11 => Arno Eigenwillig <arno@yaps.rhein.de>
F0841B11 says 34D74DC1 => Peter Simons <simons@petium.rhein.de>
34D74DC1 says CCEF447D => Stale Schumacher <stale@hypnotech.com>

The Reverse Path - Ståle Schumacher to Phil Zimmermann

We can also choose to go the other way. We may feel confident in the key that we have downloaded from Ståle's Web site but because of its key importance we wish to carry out as many checks as possible on Phil's key.
CCEF447D says C7A966DD => Philip R. Zimmermann <prz@acm.org>
CCEF447D says 6B39B945 => mathew <mathew@mantis.co.uk>
6B39B945 says C6B0A571 => Geoffrey T. Falk <gtf@math.rochester.edu>
C6B0A571 says 32DD98D9 => Vesselin V. Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>
32DD98D9 says C7A966DD => Philip R. Zimmermann <prz@acm.org>
CCEF447D says 34D74DC1 => Peter Simons <simons@peti.rhein.de>
34D74DC1 says 3ECF3225 => Christoph Teuber <ch_teuber@aworld.aworld.de>
3ECF3225 says 6CE93239 => Christopher Creutzig <C.CREUTZIG@HOT.zer.de>
6CE93239 says 3F31BA55 => Rene Mueller <rene@math.fu-berlin.de>
3F31BA55 says C7A966DD => Philip R. Zimmermann <prz@acm.org>
CCEF447D says 18239E91 => Robert C.Casas <73763.20@compuserve.com>
18239E91 says DA87C0C7 => Edgar W. Swank <edgar@spectrx.sbay.org>
DA87C0C7 says 077A2F7F => Ian Hebert <ian@braille.uwo.ca>
077A2F7F says 64827961 => Brian Lingard
64827961 says 78096D05 => Shawn Ferrier <af938@freenet.carleton.ca>
78096D05 says 4A56AF31 => Thomas Bueschgens <sledge@hammer.oche.de>
4A56AF31 says 46EFB2D5 => Uri Blumenthal <uri@watson.ibm.com>
46EFB2D5 says 4D0C4EE1 => Jeffrey I. Schiller <jis@mit.edu>
4D0C4EE1 says C7A966DD => Philip R. Zimmermann <prz@acm.org>
CCEF447D says 585A99A5 => Ron Williams <ron.williams@emerald.com>
585A99A5 says 8799331D => Joe Eversole <joe.eversole@ibmnet.com>
8799331D says F89A24F9 => Christopher Baker <1:374/14@fidonet.org>
F89A24F9 says 22D886E1 => Tom Almy <tom.almy@tek.com>
22D886E1 says 92EEF4E9 => Alan Olsen <alano@teleport.com>
92EEF4E9 says 4F0069B5 => Neal McBurnett <neal@dr.att.com>
4F0069B5 says 955EC2C1 => Phil Karn <karn@ka9q.ampr.org>
955EC2C1 says C7A966DD => Philip R. Zimmermann <prz@acm.org>
CCEF447D says 5BF376A5 => Grant W. Denkinson <G.W.Denkinson@geog.nott.ac.uk>
5BF376A5 says 23F5ADDB => Ian Jackson <iwj10@cus.cam.ac.uk>
23F5ADDB says 4B2700B9 => Ross Anderson <rja14@cl.cam.ac.uk>
4B2700B9 says A8DA7A71 => Thomas A. Berson <berson@anagram.com>
A8DA7A71 says A40B96D9 => Aviel D. Rubin <rubin@faline.bellcore.com>
A40B96D9 says A07786A1 => Betsi <certify@bellcore.com>
A07786A1 says 5826CF8D => John Gardiner Myers <jgm+@cmu.edu>
5826CF8D says C7A966DD => Philip R. Zimmermann <prz@acm.org>

Notes

To illustrate the Web of trust I have used AT&T's PathServer. It can draw a map of the relationship between keys (extremely slow), provide a text description of the links between keys (as shown) or download an ascii-armoured key block for all the keys (to enable the user to perform her own key checks).

Phil Zimmerman's key fingerprint (as are several of the key luminaries) is published in several books. In a personal, signed communication, Phil Zimmerman has confirmed that his key fingerprint published in the books listed is indeed correct.

With the help and cooperation of the people concerned I hope to be able to publish a page showing their key fingerprints. I also hope to do the same in an appendix on PGP in the forthcoming second edition of my book Virus: A computer malaise (the first edition is available now).

By looking at my key you can see the signatures and follow them through. In effect the Web of Trust rendered visible and live on the World Wide Web.


Home ~ Index ~ PGP ~ What is PGP ~ Why use PGP ~ PGP Quick Reference ~ My PGP Public Key
(c) Keith Parkins 1996-1997 -- SEptember 1997 rev 3