Crash course on cryptography: Digital certificates
Alice needs a copy of Bob's public key to encrypt messages to him using public key cryptography. And Bob needs Alice's public key to verify any digital signatures on Alice's messages. Both must be sure that they have the right public key. This is where digital certificates come in.
Digital certificates are messages that couple an identity to a public key. They are signed by the person or authority that created them. If Bob trusts that authority, he can be sure that certificates issued by that authority are genuine and so he can check that he really has Alice's public key.
An important aspect of public key cryptography is that Alice and Bob must be convinced that they have the right public key of each other. Eve could have substituted her own public key for Bob's, and then Alice would be encrypting messages intended for Bob in a way that Eve could read them. Eve could then encrypt them again with Bob's real public key so that he would not notice Alice has the wrong public key. If Eve does the same the other way around, all communication between Alice and Bob can be read by Eve and neither of them knows it!
Alice and Bob could of course meet in person or call each other over the phone to verify that they have the right public keys. This is often impractical, and Alice and Bob might not even know each other. For example, Alice could own a Web store and use public key encryption so that her customer Bob can securely send her his credit card details. Now if Bob tries to call Alice, how can he possibly know that he's talking to Alice and not to Eve?
The use of digital certificates solves this problem. Next to Alice, Bob and Eve, there is now also a trusted third party, usually called Trent because that name also starts with a T. if Alice wants to have Bob's public key, she will go to Trent to ask for a copy. Trent will then send her a message containing details of Bob's identity and Bob's public key. This message, called the certificate for Bob's public key, is signed by Trent. Alice now verifies that the digital signature is correct using Trent's public key. If this is the case, she knows that she has Bob's real public key and she now also knows that Bob is called Bob.
Eve is now no longer able to impersonate Bob by giving Alice a public key pretending it is Bob's. Since this public key is not signed by Trent, Alice will not accept it. And Alice is sure that Trent checked Bob's passport or driver's license before making the certificate.
Of course Eve might now try to pretend that she is Trent. If she can pull this off, she can listen in on everybody's communication! To prevent this, Alice should make sure that she really has Trent's public key. This should be quite easy. Trent could be a government agency or a notary public, and so she can simply visit Trent and take a copy of this public key home with her. She only has to do this once and then she can securely communicate with everyone else who visited Trent and had him make a certificate.
Alice and Bob may trust Trent because he is their local notary. But if Alice and Bob are in different cities, Alice might not know whether this person claiming to be Bob's notary is for real. Fortunately for her, Trent is a member of the National Notary Association (NNA). This association has created a certificate with Trent's public key. Alice now visits her own notary and picks up a copy of the public key for the NNA. She then asks Trent for a copy of his own certificate and for a copy of Bob's certificate. Using the public key for the NNA Alice can verify that she really has Trent's public key and that Trent is Trent. She is then confident that she also has Bob's real public key, because the certificate with that public key was signed by Trent.
As you can see in the figure, this produces a whole chain of certificates that have to be verified before Alice can check whether she really has Bob's public key. The chain can in principal be of any length. For instance, the NNA could have representatives in different states or provinces. Each representative creates the certificates for the notaries in his state. The national NNA creates the certificates for all the representatives. And maybe there is a government agency that creates a certificate for the NNA itself.
It is important to understand that if you trust the first certificate in the chain, and then accept the public key that comes out as valid in the last certificate, you implicitly also trust all the other certificates in the chain. If one notary was bribed by Eve, he could have created a certificate for Eve stating she was Bob. If one of these NNA representatives was bribed by Eve, he could have created a certificate for Eve's Notary Service and then Eve would be able to make up certificates in anyone's name in that particular state.
When to trust a certificate
By trusting the government agency that issued the certificate for the NNA, Alice also trusts that the NNA itself is doing the right thing when issuing certificates for their representatives. She trusts that the NNA would not issue a certificate for a representative who could be bribed, and that these representatives would not certify notaries that could be bribed.
It is therefore recommended that trusted third parties make clear policies that indicate when and how they issue certificates and what those certificates mean. For example, a certificate that was issued based on a request by e-mail is probably less trustworthy than a certificate that was issued based on a personal visit during which two separate forms of ID were presented. However, this first certificate might be trustworthy enough if all you're doing is authenticating people posting to your Web based discussion board.
Trusting a certificate and trusting its owner
Some systems distinguish between "trust" and "validity". If Alice thinks a certificate is valid, it means that she accepts that the information in the certificate is genuine. In other words, she is sure that the public key in that certificate really belongs to the person whose name is in the certificate. She then knows that any messages with correct digital signatures are really from the person mentioned in the certificate.
If Alice trusts the certificate, it means she thinks the person in that certificate is capable of creating valid certificates for others. If Bob were to create certificates without doing any checks, Alice would probably not consider those certificates valid.
In the above example, Alice first decides for herself that the certificate for the NNA she picked up at her local notary is valid. She then makes the decision that she will automatically trust all the certificates issued by the NNA. for the representatives. Alice could then say that she puts no trust in the certificate for representative Eve. This means that she would not trust any certificates created by Eve. However, if Alice received a message that was signed by Eve, Alice would be sure that this message really came from Eve, because she can verify the signature using the trusted certificate for Eve issued by the NNA.