on the apache.org web of trust

This document only expresses the opinion of the author, Henk Penning.


what are pgp keys and signature files ?

A very short answer to this big question : Keyservers like pgp.mit.edu, pgpkeys.telering.at and pgp.surfnet.nl are repositories of public keys. Keys can be retrieved by keyid, name, email address etc. Many keyservers are connected in a network. Additions and updates are propagated through the network.

For the long answer ...

what is key signing ?

When Alice has a key A, and Bob has a key B, Alice can sign the key of Bob: key B then has signature A.

It is the rule that Alice has to do her best to establish that

Here is the usual scenario: Get your key signed!

what is a trust path ?

A trust path from (the key of) Dave to (the key of) Eve is a list of keys
Dave -> X -> Y -> Z -> Eve
where Dave signed X, X signed Y, etc. If there is a trust path from Dave to Eve, Dave may trust that the key labeled 'Eve' actually belongs to Eve. A priori,

what is a web of trust ?

A web of trust is a bunch of pgp keys plus the connections between them, formed by key signings.
apache httpd wot
In technical terms the web of trust is a labeled, directed graph where Some special webs of trust can be identified:

why is a web of trust useful ?

When you receive a signed message, or obtain signed software, you can find out which key signed the message or the software, and retrieve the key from the keyserver. The key contains the name and email address of the supposed owner of the key.

Of course you may believe that the person named in the key, actually is the owner of the key. If you are a little more suspicious, you can use the web of trust to raise your confidence regarding the owner of the key.

A pgp path finder is software used to find shortest paths from one key to another, for instance from your key to the key used to sign some message or software.

Find trust paths from you to me, or lookup your key statistics :
your key id :
This only works for keys in the strong set.

what can I trust, ultimately ?

The short answer is nothing.

For the ultra sceptics there is no hope.

what can I trust ?

The web of trust does only one thing: it helps you to establish that some given key actually belongs to the person named in the key; nothing more, nothing less.

If you receive a siged message or obtain signed software, you have to use other ways to establish that, for instance, the message is true or that the software works. The web of trust doesn't help you in your decision to believe or not believe the message, to use or not use the software.


why does apache.org sign software?

There are a couple of reasons:

what is the apache.org web of trust ?

The apache.org web of trust is a collection of pgp keys, defined by the contents of KEYS files in www.apache.org/dist/. The KEYS files contain the pgp keys of the release managers who create signature files for the packages published in www.apache.org/dist/.

how big is the apache.org web of trust ?

how does apache.org delegate trust ?

When the Apache Software Foundation was announced (June 1999), Brian Behlendorf supposedly said
There's a lot of trust in the Apache name, and we want to maintain that

That trust is what makes people use apache software. It was earned the hard way, and must be protected at any cost.

Because it is inpractical for the ASF to independently check all software published on apache.org, it has to delegate that responsibilty to institutions like pmc@top-level-project.apache.org. They in turn delegate to persons and/or sub-projects, etc.

It is clear how the ASF is organized. However, to me, it is unclear how this delegation is formalized. How do you prove that some person, who signed a piece of apache software, has the (delegated) trust of the board of the ASF?

If some directory contains a KEYS file, are all persons mentioned in the KEYS file trusted to publish only good, trustworthy stuff? Note that the new committers guide recommends that every committer should add him/her-self to the proper KEYS file. That is a low threshold.

Earlier discussions showed that some people view the KEYS files as nothing more than a convenience for the downloaders; in other words a key in a KEYS file implies nothing about the trust that the ASF has in the key owner as an apache publisher.
In this model, the ASF is invisible and the downloader has to derive trust from

I can't answer this question.

how can the apache.org web of trust be improved ?



Scrap the KEYS infrastructure, or generate it.

Create a structure where :

The goal is to authorise objects in a tree ; if we treat hard links and symlinks to files as copies, a filesystem is a tree. There are two responsibilities:
  1. authoriser: authorises release managers and/or authorisers for subprojects
  2. release manager: inserts objects in a subtree
So, let's have signed AUTH files containing this info: For the ASF, it works like this : Note: Example: apache.org/dist/AUTH (root AUTH)
  AU ant          bodewig ...
  AU apr          pquerna ...
  AU avalon       leosutic ...
  AU cocoon       cziegeler ...
  AU directory    akarasulu ...
  AU excalibur    leif ...
  AU forrest      crossley   ...
  AU httpd        fielding ...
  AU jakarta      rdonkin foo bar # <-----------------------
  AU james        noel ...
  AU lenya        gregor ...
  AU logging      carnold ...
  AU maven        jvanzyl ...
  AU myfaces      schof ...
  AU perl         cholet ...
  AU spamassassin jm ...
  AU struts       martinc ...
  AU tcl          patthoyts ...
  AU xmlbeans     radup ...
Example: apache.org/dist/jakarta/AUTH
  AU bcel              rdonkin
  AU cactus            vmassol felipeal
  AU ecs               rdonkin
  AU hivemind          hlship
  AU jetspeed          morciuch taylor
  AU jmeter            mstover1 sebb
  AU log4j             ceki
  AU lucene            ehatcher
  AU oro               dfs
  AU regexp            vgritsenko
  AU slide             rdonkin
  AU struts            martinc
  AU taglibs           felipeal
  AU tapestry          ehatcher
  AU tomcat-3          rdonkin 
  AU tomcat-4          remm
  AU tomcat-5          yoavs
  AU tomcat-connectors mturk
  AU turbine           henning
  AU velocity-tools    nbubna
  AU velocity          rdonkin

Valid HTML 4.01 Transitional