|This page is still under construction (created from a split of another article).|
For some keys it is very difficult to verify them directly with their owner. Thus you can decide (this decision is the default setting of the base software GnuPG) to accept keys as valid if they are certified by keys which you consider
Example: You want to send an encrypted email to Steve. You are reasonably sure that Steve has the email address email@example.com (in contrast to most names email addresses have the big advantage that they are unambiguous; and they have the disadvantage that the same email address can belong to different people over time). Let's assume that it is not possible for you in time to check the key with Steve directly. You search for keys with his email address on the keyservers and find one (just one luckily). This key has several certifications by other keys and you happen to know (and consider valid) two of them. Your friends Joe and Michael have created a signature for the key which you just got from an insecure source. But their signatures cannot be forged (under normal conditions). The technical part is that your application tells you that their signatures are correct and valid. The organizational part is that you have to decide if that is good enough for you. If it is and you configure your application accordingly (or make a local signature by yourself) then your applications will consider this key valid and you can send him an encrypted message (without clicking away a lot of warnings and without being too afraid).
To make this assessment easier every key which actively participates in the web of trust should have a (really securely signed) certification policy. You may have guessed: Currently nearly nobody has one. And of course it is very important that you stick to your policy!