Caché Security Administration Guide
About PKI (Public Key Infrastructure)
[Back] [Next]

This appendix covers the following topics:

The Underlying Need
There are many situations involving computing that need security. One familiar example is how to protect information – such as for a business transaction – that is traveling across a network that is not secure – such as the Internet. Another is when there needs to be some kind of verifiable, legally binding digital signature.
One of the most common ways of providing security is through the use of public-key cryptography. Public-key cryptography is a mathematical algorithm that enables the encryption and decryption of data. Everyone who is using public-key cryptography holds two keys – one of which is public and one of which is private; the algorithm can use either key to perform an operation, such as encryption, which then means that the other key can perform the complementary operation, in this case, decryption. Using these keys and operations, public-key cryptography provides the means of providing security, such as protecting data in transit or establishing the provenance of a document.
However, public-key cryptography alone does not provide sufficient confidence of the identity of the participants in activities, particularly if those participants do not know each other personally. To provide enough confidence to be able to use public key cryptography in an unsecured setting, such as over the Internet, there needs to be a larger structure that also provides trustworthy and verifiable identification information for entities involved. Such a structure is known as a Public Key Infrastructure (PKI).
A PKI provides a means so that individuals or organizations – generally speaking, known as entities – without any direct personal knowledge of or contact with each other can be confident of each other’s identities. This depends on each of the entities trusting a third party who vouches for the identity of the other entity (also known as the other peer). This allows the entities to perform meaningful and legally binding cryptographic operations; the operations include encryption, decryption, and digital signing and signature verification.
You can use a PKI for multiple purposes:
About Public-Key Cryptography
Public-key cryptography operates on data controlled by distinct entities, where entities can be people, applications, organizations, and so on. Each entity has a private key, which is a closely held secret, and a public key, which is made widely available. (Usually, the public key is encapsulated in a public key certificate, which holds both the public key itself and identifying information about the key holder; see below for more information about certificates and certificate authorities.)
A public-key algorithm uses the two keys for the complementary operations, where either key can perform either operation. (The most commonly used public-key algorithm is the RSA algorithm, developed by Ron Rivest, Adi Shamir, and Leonard Adleman.) All functionality associated with public-key cryptography is based on this fundamental principle: data encrypted with one key can only be decrypted with the other.
Hence, if you use your private key to encrypt content, only your public key can be used to decrypt it; conversely, if someone else encrypts content with your public key, only your private key – and therefore, only you – will be able to decrypt it. This means that public-key cryptography provides a means for secure and private communications between two entities. If I send you a message that is signed with my private key and encrypted with your public key, this gives you content that you can trust as being from me (since only I have access to my private key) and that only you can read (since only your private key can decrypt it).
(Note that there is also a simpler case, in which only one entity has a key pair and certificate. This is an arrangement for situations where only the identity of that peer needs to be verified.)
The uses of public-key cryptography include:
Authentication, Certificates, and Certificate Authorities
For public-key cryptography to be useful among users who do not know each other and cannot easily perform out-of-band authentication (verification of identity), there needs to be a way to determine what public key is associated with what user. The mechanism to attain this end is the certificate, which is issued by a certificate authority (CA). A certificate is a document that is digitally signed by a trusted third party (the CA) and that ties the public key to a set of identifying information about its owner, such as a name, organization, location, and so on.
Typically, a CA is an independent organization, such as VeriSign, or within an organization. For either external or internal CAs, there can also be intermediate CAs; these serve as subordinate CAs to the uppermost or root CA. For example, an entire organization may have a root CA, and divisions or offices may each have their own intermediate CAs.
Entities do not need to use the same CA – each (or, more likely, each one’s software) simply needs to trust the other’s CA. This relationship of trusting a CA is usually established without any user intervention, such as by having a browser ship with a set of pre-approved CA certificates. For example, in Firefox 14.0, you can see a list of trusted CAs in the Tools > Options dialog, on the Advanced tab, by clicking the View Certificates button and the Authorities tab. If a user attempts to connect to a site that uses SSL/TLS and that has a trusted CA, then the user’s browser is able to authenticate the site.
Sometimes, the entity receiving the connection may also want to authenticate the entity initiating the connection. This is known as mutual authentication. Again, it does not typically require human intervention.
When two entities need to authenticate each other, they can do so using their certificates and the CA’s trusted relationship to them. Hence, when Alice and Bob attempt to communicate via, say, SSL/TLS, the SSL/TLS handshake performs authentication for each of them as follows:
As another example, suppose that a large company has its headquarters in Sao Paolo, as well as offices in Tokyo and Istanbul. This company might have its root CA in Sao Paolo, with intermediate CAs in Tokyo and Istanbul. Suppose that there are entities in Tokyo and Istanbul that need to authenticate each other. When the one in Tokyo receives the other’s certificate, it sees that the certificate is signed by the Istanbul CA, which, in turn, has a certificate signed by the root CA in Sao Paolo. Likewise for the entity in Istanbul verifying the certificate signed by the Tokyo CA.
How the CA Creates a Certificate
When an entity obtains a certificate from a CA, a number of events have occurred – frequently without being visible to the user.
First, an algorithm creates the key pair. It then obtains necessary information to describe the entity using the key pair, which has to do with the entity’s location, organization, and so on. Taken all together, this identifying information comprises a distinguished name (DN). The entity provides the public key and DN information to the CA in the form of a certificate signing request (CSR); it does not provide the private key because, again, this is a closely held secret.
The CA receives the CSR and then processes it according to its procedures (which vary by CA and by the degree of authenticity to which the certificate attests). Ultimately, the CA signs a document that binds the public key to the DN information, thereby creating a certificate (specifically, a certificate that conforms to X.509 standard).
Limitations on Certificates: Expiration and Revocation
A certificate has an expiration date. This requires the owner of the certificate to renew it regularly. And even CA certificates have expiration dates, which is one reason why you may occasionally see messages asking if you are willing to accept a non-valid certificate for a site – it may be because the site’s owner has let its certificate lapse.
If a certificate has been compromised, CAs also have a means declaring it non-valid, using what are called certificate revocation lists (CRLs). A CRL is a document that a CA publishes and that specifies all certificates for which it revokes its certification. A CRL is analogous to a list of people from whom a store will not accept a personal check; in fact, the analogy holds well, since the default case both for the CA and the store is that certificate or the check is valid, and the CRL or the list specifies the certificates or checks that are not acceptable.
Recapping PKI Functionality
The different activities of the CA and its clients are made possible because these are part of a public-key infrastructure (a PKI). To review: