What is PKI anyway?

By David Newman
Network World, 12/10/01

Simply put, public-key infrastructure is the collection of components and policies needed to issue, manage and revoke digital certificates. These certificates can then be used to authenticate any application, person, process or organization in an enterprise network, extranet or on the Internet.

Any PKI design is only as secure as its weakest component. Therefore, good PKI design requires a thorough understanding of all the components.

Although PKI's extended features are numerous and numbingly complex, the basic element is simple: PKI begins with the certificate.

At a minimum, a certificate binds identification with some means of verifying that identification. As an everyday comparison, we can look to a driver's license for functional similarities.

Like its digital counterpart, a driver's license is issued by a trusted entity - in this case, a department of motor vehicles. The license uniquely identifies its holder by stating name, address and other signifiers such as height and weight. It has a unique identification number (a public key) that lets authorized users access private information about the user. It discourages forgery and tampering through use of holograms and special paper. And it contains an expiration date. All these features of the driver's license are also critical in digital certificates.

Digital certificates differ from driver's licenses in two important regards.

First, they don't just authenticate people. A digital certificate may also authenticate an entire organization, an e-mail or IP address, or a certificate authority. The most common format for digital certificates, the ITU's X.509 recommendation, defines a range of means for identifying certificate holders.

Second, digital certificates are limited in that most don't identify the roles or functions its holder may perform. In contrast, a driver's license can authorize the holder to drive a car, but not a school bus.

The security concern here is that a certificate, by itself, offers practically nothing in the way of access control. Obviously, a security infrastructure that authenticates a user but places no restrictions on the user's actions doesn't offer much security. For this reason, network designers usually look to firewalls and VPNs, rather than PKI, to establish access control (see "PKI, firewalls, and VPNs," page 52).

The PKI X.509 working group of the Internet Engineering Task Force is working to address this issue with an attribute certificate profile that is an authorization/access control mechanism. These documents are still in draft status.

The other basic PKI building blocks include the certificate authority, registration authority, repository and an optional archive.

The certificate authority, as the entity that signs and issues certificates, lies at the heart of any PKI. Certificate authorities are typically housed in data centers, although theoretically they can be located anywhere in a network. The certificate authority signs the certificates it issues with its private key, vouching for the authenticity and integrity of those certificates.

If an attacker were to gain possession of the certificate authority's private key, the certificate authority's authority would be compromised. Thus, protecting certificate authority's private key from compromise is of the utmost importance. That means ensuring physical and network security for the certificate authority, and personnel security for the people who administer it.

Besides signing and issuing certificates, the certificate authority keeps tabs on certificate status. Certificates carry expiration dates, and it's up to the certificate authority to revoke certificates when they expire.

But what if a certificate's trustworthiness comes into question before its expiration date, such as when an employee leaves a company? In this case, the certificate shouldn't be trusted even though it hasn't expired. To handle such situations, the certificate authority maintains a certificate revocation list (CRL). Certificate users can query the CRL to determine whether a certificate remains valid.

CRLs can be retrieved by several means including

e-mail, Web and Lightweight Directory Access Protocol queries. However, all these query types assume the CRL is static, which raises security concerns about the frequency of CRL updates. To address these issues, a newer protocol called online certificate status protocol (OCSP) lets a potential certificate user query the certificate's status in real time. The latest versions of Microsoft and Netscape Web browsers support OCSP.

The registration authority is responsible for verifying the identity of certificate holders. This is a different process than certification itself, and it may happen before or after the certificate authority generates a certificate.

Registration authority can be physically separate from certificate authorities, or they can run on the same server. In some PKI designs, one certificate authority communicates with many registration authorities. If the registration authority and certificate authority are separate, securing communications between the two is critical.

A repository is simply the database that stores certificates and CRLs. Repositories aren't trusted entities, but users trust their contents because they've been signed for by a certificate authority and/or registration authority. It's important to restrict write access to the repository.

Some PKI models also include an archive for long-term storage of information that the certificate authority uses. This can be useful if disputes arise, such as contesting the amounts involved in a digital transaction. An archive can also verify signatures on old documents, such as wills or long-term bonds. Because archives certify that the information they hold was good at the time it was received, there's also a requirement that they protect their contents from tampering.

Back to the main article