PKI Best Practices (NC): Best Practices Guide for Deploying Public Key Infrastructure

An in-depth technical guide to the security technology driving Internet e-commerce.

“Planning for PKI” examines this cornerstone Internet security technology. Written by two of the architects of the Internet PKI standards, this book provides authoritative technical guidance for network engineers, architects, and managers who need to implement the right PKI architecture for their organization. Readers will learn that building a successful PKI is an on going process, not a one-time event. The authors discuss results and lessons learned from three early PKI deployments, helping readers avoid the pitfalls and emulate the successes of early PKI adopters.

Using plain and direct language, the authors share their extensive knowledge of PKI standards development in the Internet Engineering Task Force (IETF) and elsewhere. Subtle points about the Internet PKI standards are liberally sprinkled throughout the book. These nuggets provide insight into the intent of some of the esoteric topics in the standards, enabling greater interoperability.

“Planning for PKI” gathers the PKI state-of-the-art into one volume, covering everything from PKI history to emerging PKI-related technologies.

RUSS HOUSLEY is Chief Scientist for SPYRUS, a leading provider of security products. He has contributed to the development of many standards, including PKIX Part 1, S/MIME, and MSP, the security cornerstone of the U.S. Defense Message System. He is a member of the President’s Export Council Subcommittee on Encryption, and chair of the IETF S/MIME Working Group.
TIM POLK is the technical lead for PKI at the National Institute of Standards and Technology (NIST). He has participated in federal PKI projects, such as the Federal Bridge CA project, since 1995. He has contributed to the development of many standards including PKIX Part 1. He is currently the co-chair of the IETF PKIX Working Group.

PKI Basics

Chapter 2, “Cryptography Primer,” left us with the promise of public key cryptography and some unresolved problems. First and foremost, before Alice can use a public key, she needs to know who has the corresponding private key. When Alice verifies a signature, she is confirming (or denying) that Bob signed the message. If someone else has the corresponding private key, he or she sent the message, not Bob. When Alice encrypts her response to Bob, she needs to be sure that only Bob can read it. If Bob does not have the corresponding private key, he will not be able to decrypt the response. Alice also needs to know what applications are appropriate for Bob’s key. Perhaps Bob’s key should only be used to sign or encrypt electronic mail, but not to sign contracts. Finally, she needs a solution that will be scalable. That is, the solution must continue to work for Alice if she communicates with hundreds of people instead of just Bob.

This chapter introduces the basic tools of a PHI in a rather abstract fashion. There are two basic tools used in a PKI to determine who has a private key: the public key certificate and the certificate revocation list. The former will establish who, and the latter will ensure the information is up to date. The basic PKI tool that answers the question what the key can be used for is the certificate policy. The basic PKI tool for scalability-the tool that lets Alice communicate with hundreds of people-is the certification path.

In Part Two, PKI Details, we will revisit each of these topics in detail, devoting a chapter or more to each.

Simple Certificates

As described in Chapter 2, the basic problem with public key cryptography is determining who holds the corresponding private key. To answer this question, a PHI relies upon the concept of a public key certificate, or simply certificate. A certificate is the most basic element of a PHI. Each certificate contains a public key and identifies the user with the corresponding private key. For example, if Alice has a certificate with Bob’s public key, she will know that Bob has the private key.

Certificates are not really a new concept to us. They will resemble a couple of everyday objects in important ways. Those everyday objects are the credit card and the business card. The features of these objects are insufficient, but we will build the “ideal certificate” from their features. Finally, we will describe real public key certificates and contrast them with the ideal certificate.

The Business Card

The business card is inescapable. It is almost impossible to return from a meeting or conference without a handful of these little paper cards. Each card identifies a particular person and provides some additional information about him or her. In general, that information will include the person’s employer, telephone number, mailing address, and electronic mail address. Some people print their public key on the card as well, making this the most rudimentary form of a certificate.

Bob can distribute his business card to everyone he meets. By printing his public key on the back of his business card, Bob is declaring that he holds the corresponding private key. (Bob’s card is shown in Figure 3.1.) If Alice has Bob’s card, she has the public key, and she knows Bob has the private key because his name is on the front of the card. She trusts the information because she obtained it directly from Bob.

There are a number of drawbacks to this type of certificate. The user must receive the business card in person, or the user will have no basis on which to trust it. This is very limiting; all participants must have met face to face. What if Bob and Alice need to work together, but they have never met? Twenty years ago, this may not have been a realistic question, but it is a real problem today. Frequently, project teams are formed that cross geographical and organizational boundaries. There may not be a single person who has personally met every member of the team.

In addition, the information on the business card is all self-proclaimed. Bob has proclaimed that he works for Fox Consulting and that he is the Chief Technical Officer. If all of that information is true, Bob may be the ideal recipient of Alice’s wonderful project idea. Of course, “Bob” may have a reason to lie, and anyone with a personal computer can generate business cards! How well does Alice know Bob? Without additional information, Alice can only be sure that the man in the gray suit introduced himself as Mr. Burton and handed her the card.

Alice also can’t tell if the card is a forgery or has been altered since she received it. Anyone with a computer and a printer can create a business card. Is it real? People commonly update the information on their cards by hand. Is that Bob’s handwriting with the new e-mail address? In most cases, Alice can’t be sure.

It is also impossible to retrieve or correct those business cards once they are distributed. This is a problem, since the information on the card may have been true when the card was distributed, but is now false. If Bob loses his private key, it will be very difficult to contact everyone he gave a card to tell them. If the card identifies an organization, the same dilemma emerges at every job change.

Last, but not least, before Alice can use Bob’s public key, she needs to type it in. That is no small feat for a 1024-bit key, much less a 2048-bit key!

A business card meets the most basic requirement for a public key certificate-it can contain the public key and identify the user with the corresponding private key. ….