The OpenPGP message format, as used by the gnu Privacy Guard and pgp Desktop, uses a lot of confusing words to talk about trust.
This document will hopefully shed some light on these confusing words and concepts.
The OpenPGP standard traces its origins back to the early nineties. When the community was first inventing pgp, the community was also inventing the words we would use to talk about it. One group of people would use a word to mean one thing, another group would use the same word to mean something unrelated… it was kind of a mess, and is still a mess today.
This word means many different things. It could mean anything from a shared secret key to a public keypair to a certificate to even the passphrase on your certificate.
This word is confusing. If you mean to talk about your keypairs and associated user identities, the better word to use is certificate.
Pretty much nothing. It’s a set of numbers with a couple of names and email addresses attached to it. It means nothing more or less than “17” and firstname.lastname@example.org.
In order for a certificate to be meaningful, it must be a validated by a trusted introducer in a manner consistent with your security policy.
However, just because a certificate is meaningful does not mean that every user ID on that certificate is meaningful.
You are always a trusted introducer for your own certificates.
The user identity must be validated by a trusted introducer in a manner consistent with your security policy.
Your security policy is the set of rules someone else has to be follow before you will give them the ability to break your rules.
For instance, if you give your neighbor keys to your house, there is nothing to prevent your neighbor from robbing you blind. By giving your neighbor your house keys, you are giving them the ability to break your rules.
This isn't necessarily a bad thing. Maybe some emergency has arisen which your rules don't cover. Breaking your rules is not automatically a bad thing. You just want to be careful about whom you give the ability to break your rules. You want to have a process in place by which you can control who has the ability to break your rules. That’s your security policy.
What follows here is a beginning, not an ending. You may wish to have stricter rules than this. However, I suggest you not use weaker rules.
The two ways to validate certificates are direct validation and indirect validation. We’ll cover the indirect case first, since it’s much easier to understand.
If a certificate has been validated by a trusted introducer, those parts of the certificate validated by the introducer are valid.
For example: assume you trust Alice to introduce you to other people. If Alice validates Bill’s certificate, those things which she validates are considered to be valid.
There are a very wide variety of standards people apply to direct validation. For the most part, people do direct validation very poorly. It is important to have a checklist in front of you while you go through this. If any step fails, stop: you are not in a position to validate the certificate.
If the answer to all those questions are “yes,” then you may make an exportable signature with confidence. If the answer to any of these questions are “no,” then think long and hard. You are going to be giving someone the ability to break your security policy: do you really want to do this?
Sometimes the answer to this one is “yes.” If that’s the case, you may make what is called a local signature on those user identities you wish to validate.
An exportable signature is one that is permanently attached to the certificate and will follow it around forever. Once you send the certificate to a keyserver, it will be there for a long, long time.
A local signature is one that exists only on your local machine. When you send the certificate to the keyserver, the local signature will silently be stripped off.
You may think of it as, “an exportable signature means ‘I vouch for this certificate,’ and a local signature means ‘I think it’s right but I don’t want anyone to rely on it.’”
On the internet, anyone can pretend to be anyone. There are undoubtedly a lot of certificates claiming to belong to email@example.com. It’s simply not possible for OpenPGP to distinguish between those who are lying about their identities and those who are telling the truth.
By validating a certificate, you are taking responsible steps to ensure that you’re not being deceived.
A trusted introducer is a validated certificate belonging to someone whom you trust to make honest introductions. You then give this certificate a trust signature, which tells OpenPGP “I trust this person to make introductions on my behalf.”
For instance, if I have validated Alice’s certificate, the fact Alice has validated Bill’s certificate will mean nothing to me. I haven’t validated Bill’s certificate, and I don’t trust Alice to make introductions.
If I have validated Charlene’s key and given her a trust signature, and Charlene in turn validates Bill’s certificate, then my OpenPGP program will consider Bill’s key to be validated.
The Web of Trust is a spiderweb, with you in the very center. Each certificate you have validated and given a trust signature sits near you at the center; all the certificates they have validated are one step farther away. In this way, you can imagine it as a roadmap of confidence: “I trust Alice, who has validated Bill’s key. Over the years, I have come to trust Bill, so I have given his certificate a trust signature. Bill in turn introduced me to Charlene and David…”
That’s the Web of Trust, right there.