The point of public key encryption

is that the public key component

is really public.

That is, any user can send his or

her public key to any other user or

just broadcast it to the world.

Although this approach is very

convenient, it has a major weakness.

That is, anyone can forge

such a public announcement.

Some user could pretend to be Bob,

and send a public key to another user

such as Alice, and tell Alice

that this is Bob’s public key.

The result is that when Alice

sends a private message to Bob

saying she encrypts it

using Bob’s public key.

But remember this Bob’s public key

is actually forged by the attacker.

Then the message can be

intercepted by the attacker, and

can be read by the attacker.

Now, at some point hopefully,

Bob can discover that there’s

a forgery going on and

a fake public key of his was being used.

But then what can Bob do?

Bob can send Alice another

message saying that,

hey, this is my real public key.

But how could Alice tell?

That is, how could Alice tell that the

previous key was a forgery and this key,

that Bob just sent, is real.

The solution to this problem of

public key forgery is to use

a public key certificate.

In essence, a certificate consists

of Bob’s public key and Bob’s

information such as the user ID, let’s

say his name and address and so on.

The certificate authority’s information.

And the whole blog is signed using

the certificate authority’s private key.

The certificate can also

include other information,

such as the period of validity of

this certificate, that is, for

how long this certificate is valid for

this public key, say, one year.

Now let’s see how certificate is

created, and how it is verified, and

how it is being used to

distribute public key.

Suppose Bob wants the certificate

authority CA to create a certificate for

his public key.

Bob would contact the CA and provide

authentication information such keys

driver’s license and so on, and

then he will send his public key to CA.

The CA will then put his ID,

his public key and

other information such as the period

of validity together and then hash it.

And then the CA will use his

private key to sign the hash.

So that creates the certificate

of Bob’s public key.

Now Bob can send this public key

certificate to anybody such as Alice.

When Alice receives this

public key certificate,

she can first extract the key types

of information of Bob’s idea,

public key, and all the information.

And then she will hash this data,

and then Alice will also use

the certificate authorities public

key to decrypt the signature or

verify the signature and

compare these two hash values.

If they match, that means this public

key has been properly signed by the CA.

In other words, this public key of

Bob’s has been validated by the CA.

So this is how public

key certificate works.

Now of course,

the underlying assumption is that.

The CA is a trusted party

by everybody involved.

In practice, the CA is a well-known

company such as Verisign,

Microsoft, Google, or Apple, and

the public keys are already stored in,

for example your web browser.

That is with these public keys already

configured on your system, they can

automatically validate public key

certificates signed by these entities.