A public key infrastructure or PKI is required to actually be able to use public key cryptography in the real world effectively. It is supposed to solve the problem of authentication and validation of public keys, answering the question: "How do I know that this public key that I'm getting really belongs to the entity I think it belongs to?" This notion is central to all systems that use public key cryptography for authentication.
Without such a scheme, it is possible for a man in the middle attack to occur, where a rogue entity pretends to be an entity you trust to you, and pretends to be you to the actual entity you trust. In between, it's subtly manipulating the transactions between you and your trusted entity, maliciously and unobtrusively. This happens because you and your trusted entity actually have no idea who they're really communicating with. A lot of more insidious stuff can be done by a potential attacker as well. The existence of a PKI is supposed to thwart this.
Most PKI's (such as X.509) operate on a hierarchy of trust, with the root certification authorities or CA's acting as the central repository of trust. This role is played by companies like Thawte Consulting and Verisign today, among many others. These root CA's provide the service of ultimately authenticating and validating public keys, by issuing certificates. Certificates consist of a public key along with some auxiliary information that describes the entity who is supposed to own the public key (in X.509 this information is called the certificate's distinguished name), all digitally signed by the CA's root certificate. Because the CA should be trusted by all participants in the PKI system, this trust can be transmitted to the certificates that the CA signs. Other certificates can be trusted because they were signed by a chain of certificates that ultimately leads back to a root certificate. This is the case with the PKI implicit in SSL, TLS, S/MIME, and IPsec.
Another means that is less centralized than the above scheme is the technique used by PGP. In contrast to the above hierarchy, this technique does not require a central certification authority to act as a trusted third party, this is the web of trust model. Here, every user can potentially act as a repository of trust. If you trust some entity, you can sign that entity's key, allowing other entities who trust you to trust that entity as well. Keys that have been signed by other entities whom you trust are also accepted in the same way. This works very well if out of band communication is possible to further establish whether the trust is warranted or not. It's one thing that most users of PGP never seem to understand. It seems that even Microsoft fails to understand this crucial part of PGP's workings: the public key they use to sign their security bulletins on Bugtraq and other security fora is not signed by anyone in this way, so it is not present within the web of trust.
Another responsibility of whoever maintains these repositories of trust, be it a CA or the individual users in a web of trust, is what to do in the event that a key becomes invalid for whatever reason. In the hierarchical PKI the root CA's maintain a certificate revocation list which is the responsibility of users of the system to check regularly. Unfortunately, few SSL/TLS implementations take these steps, and some (such as Microsoft's CryptoAPI) actually make this nearly impossible to do at times. For web of trust-based PKI's it's a little more thorny. The entity whose key has been compromised must issue a revocation certificate that one would hope propagates to the rest of the community using that entity's old key.