Certificates

One important part of the digital signature process was explained above as follows: Let us assume that Alice has given her public key to Bob. But this imposes quite a big restriction: Bob can only verify signatures from such parties with whom he has already been in contact beforehand. It would be better if Bob could get Alice’s public key just when a need to verify her signature arises, without any preparations in advance.

A straight-forward solution would be that Alice provides her public key together with the message that she has digitally signed. But now we encounter a ”chicken-and-egg” problem because the whole point of the digital signature is to verify that the message is really coming from Alice, and not from somebody who just pretends to be Alice. If the public key of Alice is delivered together with the message, and this public key should be used to verify the origin of the message, then an imposter could just include a fake public key to the delivery, i.e., a key for which the corresponding private key is in the possession of the imposter, not Alice.

One way out of the ”chicken-and egg” situation is found if Alice’s public key is signed by somebody whose signatures Bob is able to verify, e.g., by some authority. Such digitally signed information is called a certificate. Note that the authority is just endorsing Alice’s public key, the authority does not have to take any stand on messages that Alice is sending.

A typical example where certificates are needed is when a user wants to get some assurance of the validity of the web page he visits. HTTPS protocol enables this and the authentication of the web server is carried out by digital signatures, based on a certificate.

All browsers provide information about the certificate. In our example, the information can be found as shown below.

What has been signed is the fingerprint of the information in the certificate. The authority who has signed the certificate is ”DigiCert SHA2 Extended Validation Server CA”.

Public-key infrastructure

Our solution to the ”chicken-and-egg” problem did not remove all restrictions. We still assumed that

• Authority A has verified somehow Alice’s identity and, consequently, has signed Alice’s public key;
• Bob has somehow acquired the public key of the same authority A.

Such an authority A is called a Certificate Authority (CA). But it should be possible for Alice and Bob to be in contact with different authorities. Otherwise, the CA easily becomes a bottleneck in the system.

A typical solution for this problem is to arrange a hierarchy of authorities. For example, Bob could have a public key of a root CA, e.g., in-built into his browser. This root CA would then provide certificates for other CAs that are one level lower in the hierarchy. These CAs could provide certificates for public keys of regional CAs, and Alice could be in contact with one such regional CA.

Bob would need to verify all certificates in a certificate chain. Once all certificates are verified, Bob is finally able to verify Alice’s signature.

All CAs, together with some other authorities (that are needed, e.g., for managing revoked certificates), form a public-key infrastructure (PKI).

In our HTTPS example, the certificate chain has a length of two. ”DigiCert SHA2 Extended Validation Server CA” has provided a certificate for the F-Secure website, and ”DigiCert High Assurance EV Root CA” has provided a certificate for ”DigiCert SHA2 Extended Validation Server CA”. The root CA public key needs to be embedded in the browser for successful authentication of the website.

The actual signature value of the certificate is provided as shown below.

Remember to check your points from the ball on the bottom-right corner of the material!