When PGP is given a certified key, it asks if you trust the signer to
introduce new keys to you. If not, then the key will not be certified
in your key ring. When you add a key, you attribute a certain level of
trust to the person; people you trust can certify keys to be added to
your key ring. If you get a key from an unknown person, but someone
you trust has certified it, PGP will assume that you will accept the
key as well. The bottom line, again, is to be careful with delegating
trust and accepting keys on blind faith. The key distribution and
certification chapter in Garfinkel's book covers this material with
some outstanding examples.
One-on-one key distribution is slow, and not always convenient. What
do you do when you need someone's public key and can't wait for them
to send it to you? Several public key servers are available, such as
the MIT Web server (http://www-swiss.ai.mit.edu/~bal/keyserver.html).
There are also e-mail-based public key servers, including
firstname.lastname@example.org and email@example.com.
Send mail with a subject of INDEX and you'll get a key directory;
extract a single key with a GET. The MGET command fetches multiple
keys, using regular expression syntax for the user names, and ADD
submits your key to the server for public distribution.
King George should be able to read this: digital signatures
All of the PGP examples discussed to this point let you safely
exchange keys and data with groups of users on a one-to-one or
one-to-few basis. How do we solve the broadcast problem outlined in
the introduction, where we want to check the authenticity of a message
sent to an alias? In more general terms, how do we verify the identity
of any message's sender? Having your public key means I can send you a
private message without fear of interception. But how do you know the
message came from me, and not someone pretending to be me who happened
to have your public key? Digital signatures fill the technology gap.