Digital Certification

One of the primary goals of a digital certificate is to confirm that the public key contained in the certificate is, in fact, the public key belonging to the person or entity to whom the certificate is issued. For example, a CA may digitally sign a special message (the certificate information) containing the name of some user, say "Alice," and her public key. This is done in such a way that anyone can verify that the certificate information message was signed by no one other than the CA, and thereby develop trust in Alice's public key.

The typical implementation of digital certification involves a signature algorithm for signing the certificate. The process goes something like this:

  1. Alice sends a signed certification request containing her name and her public key to a CA.
  2. The CA creates a special message, m, from Alice's request and signs it with its private key, obtaining a separate signature, sig, in the process. The CA returns the message, m, and the signature, sig, to Alice. The two parts together form a certificate.
  3. Alice sends the certificate to Bob to convey trust in her public key.
  4. Bob verifies the signature, sig, by using the CA's public key. If the signature proves valid, he accepts Alice's public key.

As with an ordinary digital signature, anyone can verify, at any time, that the certificate was signed by the CA, without access to any secret information.

The scenario just presented assumes that Bob knows the CA's public key. That key could be obtained by getting a copy of the CA's certificate, which contains its public key.

A broader application of digital certification produces a certificate that includes not only Alice's name and public key, but also other information about Alice. Such a certificate is usually called an extended certificate. Extended certificates are more than stepping stones in a digital hierarchy of trust. They enable the CA to give Bob a means of trusting not only Alice's public key, but also that other information. The other information may include, for example, Alice's e-mail address, her authorization to sign documents of a given value, or her authorization to sign other certificates.

Because certificates have a valid time duration, it is possible for the certificate to expire and no longer be valid. It is also possible for certificates to be revoked by the CA for other reasons. To handle this situation, the CA maintains a list of revoked certificates. This list is called a certificate revocation list (CRL), and it is made available to users of the network, so that they can determine the validity of any given certificate.