A complete secure email system needs to protect rather more than its
messages and its session keys. The integrity and authenticity of the
public keys must be protected, as must the privacy of the private keys.
PGP maintains collections of public and private keys in files called
``keyrings''. In normal usage, there are two keyring files, called
pubring.pgp and secring.pgp
,
though more may be used if required.
The secring file contains the private keys belonging to a particular person. It is normally protected by IDEA encryption, with a passphrase to prevent its contents being used by anyone but the owner. Note that a person may have several private keys in use --- each may correspond to that person acting in a different role, for instance --- and that copies of a private key may exist on several keyrings --- e.g., that for a group of people sharing a role such as Postmaster.
Public keys, by their very nature, do not need their privacy protecting,
and so are not normally encrypted. However, maintaining and examining
their integrity and authenticity is of great importance. A public key
consists of some binary data (the details of which are unimportant
here), a ``keyID'' and a collection of ``userID'' records. The keyID is
an eight-digit hexadecimal number which identifies a particular public
key.
A userID usually contains the name and email address of the owner of the key; there may be more than one userID on any one public key. The PGP program itself does not normally allow anyone but the owner of the corresponding private key to change the userIDs in a public key, but it is possible for them to be changed. A malicious eavesdropper (traditionally called ``Eve'') could, therefore, add their own email address to someone else's (``Bob's'') key and attempt divert email away from the rightful recipient.
When ``Alice'' wants to send private email to Bob, she may unwittingly send it to the phoney address, that is to Eve. Eve is unable to decrypt and read the email intended for Bob, as Eve does not have Bob's private key, but neither will Bob be able to read it, as he never received the mail. This is a denial of service attack. (Incidentally, it also demonstrates why one should resist the urge to use a PGP public keyring as an address book.)
Much worse is that Eve could create a new key pair (private and public) and attach a userID of some other person or role, Bob's for example. Unwittingly, Alice would then be transmitting mail securely to Eve, if we assume that Eve can intercept the email before it actually reaches Bob. Such interception could be quite simple if Eve were the Postmaster for Alice's site. Eve can now read the mail and send on a copy to Bob, suitably encrypted in Bob's real public key. If Eve were dastardly enough to pull the same trick on Alice, she could even use her fake Alice-key to pretend that Alice had signed the forwarded mail. The standard term for Eve's actions (i.e., those of an active participant as distinct from a passive eavesdropper) is a ``man-in-the-middle attack''.
To guard against some of these attacks, userIDs can and should be signed
(in the digital signature sense) by one or more private keys. A
signature on a userID indicates that the owner of the private key making
the signature believes that the userID on the public key truly belongs
to that key's apparent owner. In particular, self-signing a userID
(using the private key corresponding to the public key on which the
userID appears) guards against malicious addition of extra userIDs.
More important in practice, however, is that userIDs be signed by
trustworthy owners of private keys elsewhere. If Alice signs a userID
on Bob's public key, it is a public statement that Alice believes that
that public key and userID truly belongs to Bob. If Charles now obtains
a copy of Bob's key, he may be satisfied that the key truly belongs to
Bob (that is, the person named in the userID) if he (Charles) believes
Alice to be trustworthy. In the jargon, Alice is acting as an
``introducer'' or a ``certifier''. It is possible to set up chains of
trust (Dora trusts Charles' assertion that Alice is trustworthy ...) and
PGP supports this notion in a simple manner. A simple chain of trust is
traditionally known as a ``certification heirarchy''. In the JANET
environment, for example, each institution could sign the keys of its
members, with the institutional key itself being signed by a UKERNA-held
key. PGP actually provides rather more than a single chain of trust ---
userIDs may be signed by several keys, and each signer may be assigned a
degree of trustworthiness by the user of the public key. In this
manner, a complicated ``web of trust'' may be built up.