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.
- a pgp key is a piece of data used to crypt and/or sign stuff ; it has a keyid and contains the name and email address of the owner.
- a pgp key has a part that is private (the secret key) ; the owner must vigorously protect it from prying eyes
- a pgp key also has a part that is public (the public key) ; it should be submitted to the keyservers, so everyone can grab it
- the owner can sign a file with his/her secret key ; the signature often goes in a separate signature file
- if you have obtained a file and a signature file, you can
- determine the keyid of the key that was used to create the signature file
- grab the key from a keyserver
- determine that your file is an exact copy of the file used to create the signature file
For the long answer ...
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:
- Bob is who he says he is, and
- key B really belongs to Bob.
Get your key signed!
- Alice and Bob meet face to face
- Bob brings a photo ID, a passport for instance
- Bob brings a listing of his public key, stating the key's id, fingerprint, uid's etc ; something likepub 768R/92A4D699 1995-04-11 Henk P. Penning <firstname.lastname@example.org> Key fingerprint = 5D C8 61 0E 99 4C FE 1C A9 A0 45 F3 67 63 F1 1B uid Henk P. Penning <email@example.com>
- Alice checks Bob's identity using the photo ID
- Bob gives Allice the listing of his public key ; Alice signs it to avoid misstakes
- Alice goes home, and if convinced of Bob's identity, retrieves Bob's public key from a keyservergpg --keyserver ... --recv-key key_B
- Alice checks the fingerprint of the retrieved key, with the paper listing of Bob's keygpg --fingerprint --list-key key_B
- if all is well, Alice signs key B using her own secret key Agpg --edit key_B Command> ? # help Command> l # list uids Command> fpr # get fingerprint Command> uid 2 # Command> uid 5 # pick some uids Command> uid 7 # Command> sign # Command> save # or quit, to back out
- to establish that Bob realy owns key B, Alice exports Bob's public key to a file and crypts the file with Bob's key ...gpg -a --export key_B | gpg -a -e -r key_B > msg.asc... and mails it to Bob
- Bob decrypts the file containing the signed key and adds it to his keyring ; he uploads his signed public key to a keyservergpg msg.asc gpg --import msg gpg --keyserver ... --send-key key_B
- now everyone can see that key A signed key B
- There are tens of thousand of people who want to sign your key.
- biglumber.com has lists of people (in your area) willing to sign keys.
A trust path from (the key of) Dave to (the key of) Eve is a list of keysDave -> X -> Y -> Z -> Evewhere 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,
- shorter paths are better than longer paths,
- multiple, disjunct paths is better than having a single path.
A web of trust is a bunch of pgp keys plus the connections between them, formed by key signings.In technical terms the web of trust is a labeled, directed graph where
Some special webs of trust can be identified:
- points represent PGP keys
- arrows (directed lines) represent signatures ; A -> B means that key A has signed key B
- the distance from point A to point B is the length of a shortest path from A to B
- The web of trust consists of all pgp keys plus the connections between them, formed by key signings. It contains millions of keys.
Most of the keys in the web of trust are singletons: they are not connected to the web because they are not signed by another key, nor were they used to sign other keys.
As far as trust is concerned, singletons are useless. Everybody can create a key with some name and email address. Only signed keys can possibly be trusted to belong to the person named in the key.
- The strong set is the biggest subset of the web of trust such that for every pair of points (keys) there is a path from one to the other.
Technically it is the largest strongly connected component of the web of trust.
The size of the strong set is approximately 34,000. The amazing thing is that the mean distance between keys in the set is between 5 and 6. So, usually you can go from one key to any other key in only 5 or 6 hops. Read more...
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.
The short answer is nothing.
For the ultra sceptics there is no hope.
- you can't trust the things you did yesterday, because you can't trust your memory
- you can't trust software you didn't write or hardware you didn't build
- you can't overlook the possibility that apache.org is a fake, set up especialy to lure you into using bad software
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.
There are a couple of reasons:
- integrity: Tampering with signed files can always be detected. Once a signature file is made with some key for some file, it is impossible to change the file and/or the signature file (even a little) and keep them consistent.
- accountability: If software in an archive is signed, you can find out who put de software in the archive.
This is important for
- apache.org: many people can put stuff in the archive ; many people can move stuff around. In case of trouble, apache.org can find out who is responsible for putting the data in the archive.This is specially important in the apache.org setup where it is standard to have group writable files.
- users of apache software: signed software allows users to establish who published it. If that person is in the apache web of trust, the user can have some confidence that the software has the approval of apache.org.
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/.
- Currently there are some 150+ KEYS files. All (sub)projects have at least one ; see the overview and an example.
- The KEYS file should contain (at least) the public keys of the release managers of the (sub)project.
- Instructions for adding keys abound ; it is unclear if/when keys should be removed.
- the KEYS files contain some 300 different keys
- some 160 keys are used to sign software but only some 75 keys are signed by other keys in the set
When the Apache Software Foundation was announced (June 1999), Brian Behlendorf supposedly saidThere'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 firstname.lastname@example.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.
- his/her trust in the key-owner as an individual ; for most downloaders this is useless because they only trust the ASF, not individuals
- the fact that the software is in apache.org/dist/ ; in this case the signature and the signer are not relevant
- Far too little software is signed (see pgp checks), currently, roughly 50% of the packages is signed.
The situation has improved ; almost 99% of the packages is signed.
- Far too few keys are signed within the apache web of trust: Only one third of the keys used to sign software are connected to the apache web of trust (see web of trust).
The situation has improved a little, but less than 50% of keys used to sign software are connected to the apache web of trust.
- In the apache.org administration, it is impossible to link information about a person and PGP keys. Each committer has an account, but is unclear which keys are associated with it, if any.
For instance, if there is something wrong with a signature (inconsistencies, expired/revoked keys) it is impossible (in general) to find out which user is responsible.
- What are KEYS file for? There seem to be two schools of thought:
- A KEYS file is a repository of keys for the convenience of downloaders, although it is unclear how downloaders are helped ; they can import the KEYS file, and then what?
- the presence of a key in some directory/KEYS file, indicates that the owner of the key has the permission to publish data in directory
For (1) there are better solutions like pathfinders, presentation of the web-of-trust concerned, etc. Currently (2) is underdeveloped. It isn't formalised ; nobody checks completeness or consistency.
- The ASF is far too open to a trojan attack ; unsigned software is common ; changes in the /dist/ tree aren't logged or monitored ; many directories are group writable (anybody in the group can put files in /dist/ ) ; many files are even group writable (anybody in the group can change the contents of such files); some groups are very large (case in point : the java-repository and group apcvs with 1000 members).
It would appear that this practice is a remnant from the past when the ASF had only a few projects, and was simply never changed.
- The KEYS, .md5, .sig and .asc files are distributed to the mirrors. I think it serves no useful purpose. It would be easy to have them in /dist/ and not distribute them to the mirrors (exclude them in rsyncd.conf).
It would be better to make them available through a secure (https) server ; that is what people expect.
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:
- the ASF authorises projects
- projects authorise release managers
- projects authorise sub projects
- comitters (esp release managers) specify their key(s)
So, let's have signed AUTH files containing this info:
- authoriser: authorises release managers and/or authorisers for subprojects
- release manager: inserts objects in a subtree
For the ASF, it works like this :
- to authorise users to sign AUTH files in subtrees sub1, sub2 :AU sub1 user1 ... AU sub2 user2 ... ...
- to authorise Release Managers in a subtree, the AUTH file (in the root of the subtree) contains lines like :RM user1 RM user2 ...
- The AUTH files must be signed by someone authorised higher in the tree
- The AUTH in the root of the tree (root AUTH) must be signed by the ASF key (to be created)
It can be inconvenient and insecure to require that the root AUTH file must be signed by the ASF key. So, there will be a ROOT file, signed by the ASF key, containing the authorisers of the root AUTH file.
- the ASF
- has a ASF key which must be cross signed by the current chairman, president, whatever
- has a ROOT file
- indicating which users, typically officers, can sign the ASF's root AUTH file
- signed by the ASF key
- has a root AUTH file
- indicating which users, typically the pmc ASF members, can sign the project's AUTH file
- signed by someone authorised in ROOT
- every project
- has a AUTH file
- indicating its release managers and/or the authorisers of its subprojects
- signed by someone in the root AUTH file
- every subproject
- has a AUTH file
- indicating its release managers and/or the authorisers of its subsubprojects
- signed by someone in the project's AUTH file
- every committer
- has a file $HOME/.pgpkey that contains his/her public key
- is asked for at least (at most :-) one pgp key on the application form ; this key should be on the key servers etc ; passwords, certs etc are sent to them, crypted with that key ; release managers should have keys in the PGP strong set
Example: apache.org/dist/AUTH (root AUTH)
- with AUTH files, for every package in /dist/, we can present a downloader with a proof that the publisher of the package is authorised by the ASF
- instead of refering to authorisers and release managers by login, we could refer to key_ids in AUTH files. This is more straight forward, but also more error prone.
It has to be login and key_id ; when an account is broken, it is easy to add a key to ~user/.pgpkey.
- if we can use keyman to implement this, fine.
- we can check the $HOME/.pgpkey for doubles and other curiosa
- for java-repository, we can allow everybody to be a release manager with "RM *", brr.
- we lose the KEYS files, but we can generate them if we want them
- based on current owners of TLP/KEYS
- the stable situation would be : the members on the project's pmcAU 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
- based on current owners of jakarta/*/KEYS
- in this example, jakarta/AUTH must be signed by users rdonkin, foo or barAU 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