Out of the blue, there are only strangers. Two people who don't know each other beforehand cannot, by themselves, establish a secure communication free of impersonation by third parties, because that's not defined. I cannot make sure that I talk with "Bob" if I have no reference framework for who or what "Bob" may be.
Suppose that Alice wants to talk securely with Bob. She has an a priori notion of "Bob". She does not want to talk to just any Bob, but with a specific Bob. Let's take an example: Alice wants to do business with Acme Ltd., a "well-known" corporation. From the point of view of Alice, there is a large body of evidence that there is such a thing as a corporation known as Acme Ltd, which sells a specific kind of goods and/or services that Alice is interested in. Alice thus wants to talk to an authorized salesman from Acme Ltd. Authorized by whom ? By Acme Ltd, of course. If Acme Ltd. says that Bob is the man to talk with, then Alice wants the public key of Bob, that Bob, the one and unique Bob from Acme Ltd. That Bob is defined as "the Acme Ltd salesman". It is Acme Ltd who asserts Bob's identity. In that case, sending to Alice the public key of Bob becomes naturally Acme's job.
Thus, Alice will receive Bob's public key from Acme Ltd. How does Alice know that what she receives really comes from Acme Ltd, the corporation ? There again, this depends on Alice knowing Acme's public key, bound to Acme's identity as asserted by... whoever is in position to give names to corporations. This usually is a chamber of commerce: the corporation is registered with that chamber, and the chamber is the entity which says "this corporation bears that name". Thus, the chamber of commerce should send to Alice the public key of Acme Ltd. Of course, this sending will use some sort of authentication (e.g. a signature) so that Alice knows that it really talks to the actual chamber of commerce.
So Alice now needs to know the chamber of commerce's public key. Since chamber of commerces tend to be public entities, this gets us to the state or country which contains that chamber of commerce. And so on...
Here I am retracing the classic hierarchical public-key infrastructure model: you get public keys from the entities who are in charge of defining names. There could be some sort of delegation. For instance, if Alice visits Acme's Web site, and the Web site uses HTTPS (i.e. SSL), then that Web server will present a certificate. That certificate is signed by a Certification Authority, which is not operated by the chamber of commerce; instead, it is a private entity who accepted to sign the certificate because Acme's sysadmin presented to the CA some documents, emanating from the chamber of commerce, which demonstrate that the certificate request really comes from Acme Ltd.
With some kind of domains (notoriously the .com, .org... domains), the coupling is looser: a certificate will be issued to a requester as long as he demonstrates that he technically controls the relevant domain. It is assumed that if there was some foul play (e.g. DNS poisoning) then the true Acme Ltd will complain at some point, and certificate revocation will be employed to fix the issue. This is still hierarchical because the chamber of commerce, state... will be invoked during litigation to demonstrate that there is a corporation named Acme Ltd, and the name "Acme" really belongs to Acme Ltd.
The naming, in the legal sense of the term, is intrinsically hierarchical. It is a monopoly of modern states; indeed, it was a cause of conflict in many countries during the last two or three centuries (in older times, names were handled by the "community", usually the local church, not by any central state). However, a decentralized, community-driven naming can still be used.
For instance, suppose that you want to send a private email to Linus Torvalds, creator of the Linux operating system. What notion of identity will you use ? Do you want to talk to "Linus Torvalds", as defined by the Finnish authorities (he is from Finland) ? Or do you want to talk to the famous Linus Torvalds, creator of Linux ? This is a case where the notion of identity is driven by fame, i.e. Linus Torvalds is whoever is designated as Linus Torvalds by a lot of people.
This leads to the Web of Trust. This uses the same concept of certificates as the PKI (a certificate being an object containing a name and a public key, and signed by someone). However, in the WoT, everybody acts as a CA. We don't use "naturally designed" CA. Every single person can simply assert bindings between identities and public keys.
How can a WoT provide any kind of security ? Liars exist. Alice may build a chain from her to Bob:
- Alice knows Charlie's public key (Charlie is a friend of Alice).
- Charlie knows Darren's public key, and has issued a certificate for that: the certificate contains Darren's name and Darren's public key, and is signed by Charlie.
- Darren knows Ernest's public key, and has issued a certificate for him.
- Ernest knows Bob's public key, and has issued a certificate for him.
Alice thus knows Darren's public key provided that she trusts Charlie for not being a liar (or being very gullible). Charlie is Alice's friend, so Alice may make some good assumptions on Charlie's reliability. Now Alice knows Ernest's public key, provided that Darren is not a liar. So Alice must trust not only that Charlie is not a liar, but also that Charlie is good at judging people and would not have issued a certificate to a liar. Then we get to Bob: for that, Alice must trust that Charlie is not a liar, would not have issued a certificate to a liar, and would not have issued a certificate to someone who would accept to issue a certificate to a liar. This begins to entail a lot of nested assumptions...
The important point is that the WoT relies on community-driven identities: an identity is defined by a lot of people agreeing on it. The WoT is secure not because you build and verify one chain, but many chains which go through distinct people's keys, and they all agree to assert that Bob is Bob. This is the oft-forgotten necessary condition for security -- and, in practice, it does not work well (or at all). You can already consider yourself lucky if you can build one chain from you to your intended recipient.
So there are always "authorities". With a classic hierarchical PKI (as is used, for instance, in X.509 certificates for SSL servers), the list of such authorities can be known and controlled by each user (this is the "trusted root" certificate store in his OS or browser). With a Web of Trust, the authorities are "the people" and security relies on "the people" to be, on average, honest (there can be liars, but most people are not).
Unfortunately, the Web of Trust will yield enough security only at great expense: the graph of certifications must be very redundant, and whenever you are trying to validate the purported public key of someone, you must gather many distinct chains, and verify them all. If you do not do that, then Evil People (insert your favourite three-letter agency here) could easily bootstrap a fake identity by bribing or fooling two or three persons.
So you cannot avoid "authorities", but you can choose your poison. There is, though, a powerful mitigation called memory: if, at some point, you obtained the public key of someone, then you can remember it and use that key thereafter. This is the model of SSH (the .ssh/known_hosts file) and it works well with usual OpenPGP implementations (that's called "your keyring"). It is not perfect, though, because memory-based PKI must still be bootstrapped (to remember a public key, you first have to learn it) and does not work well with key renewal or revocation.
