- Shopping Bag ( 0 items )
An in-depth technical guide on the security technology driving Internet e-commerce expansion.
"Planning for PKI" examines the number-one Internet security technology that will be widely adopted in the next two years. 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. The authors discuss results and lessons learned from early PKI pilots, helping readers evaluate PKI deployment impact on current network architecture while avoiding the pitfalls of early technical mistakes. Four technical case studies detail the do's and don'ts of PKI implementation, illustrating both successes and failures of different deployments. Readers will also learn how to leverage future PKI-related technologies for additional benefits.
Written by the architects of Public Key Infrastructure (PKI), this book provides authoritative technical guidance for network engineers, architects, and managers who need to implement the right PKI architecture for their organization.
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.
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. However, Alice should be nervous about implementing security with a certificate that is so easy to forge or alter. In addition, any tool that requires face-to-face meetings and retyping keys is hardly scalable.
The Credit Card
Almost everyone is familiar with the credit card. In general, a credit card does not contain a public key, so it really isn't a certificate at all. However, the basic problem is very similar. In this arena, Alice wants to determine who is associated with an account number. The techniques used to determine who provide an excellent counterpoint to the model of the business card.
The credit card certainly shares some features with the business card; it includes the name of the cardholder and the account number. If this is a corporate card, it names the company or organization as well. It is missing the contact information (for example, the telephone number and mailing address). However, it has several important features that the business card lacks. The credit card includes the logo of the issuer (for example, VISA, MasterCard, American Express, or Discover). A credit card includes an expiration date. Sometimes it includes a holographic image, and most of the information is in raised letters. Finally, the cardholder has signed it on the back. These features provide some very different properties from those we found in the business card certificates.
First, credit card use is not restricted to parties who have met. Credit cards can be used to purchase items over the Internet or by telephone. The basis for trusting credit cards does not involve the cardholders, so it doesn't matter if they have met. The credit card issuer is proclaiming this information to be true, not the cardholder. People accept the card explicitly because they trust the issuer, not because they trust the cardholder.
There are a number of features to help Alice decide if Bob's credit card issued by Trusty Cards Corporation (Figure 3.2) is genuine for card present transactions. People can generally tell if a credit card seems legitimate by the look and feel. If the card includes a recognizable hologram, that distinguishing characteristic makes the card more difficult to forge. The cardholder's name, account number, and expiration date are all in raised letters. It would be difficult to change that information once a card has been issued. Alice can look at the signature stripe on the back of the card. The signature is difficult to erase, so a thief would have to duplicate Bob's signature.
The Trusty Cards credit card company cannot retrieve Bob's credit card when the information becomes out of date (for example, when Bob quits paying the bill) anymore than Bob can retrieve his out-of-date business cards. However, the credit card's expiration date limits this problem. Issuers recognize up front that the information may not be good forever, so they include an expiration date. After that date, Alice knows not to accept the card. This is not a complete solution, though. Bob may quit paying the bill long before the card expires.
Finally, the credit card includes that magnetic stripe. Instead of typing the information into a computer or sales register, Alice swipes the card through a magnetic stripe reader. All the information she needs is transferred automatically into the system. This is a great improvement over typing the public key that was printed on the business card...
PKI Components and Users.
X.509 Public Key Certificates.
Certificate Revocation Lists.
Building and Validating Certification Paths.
PKI Management Protocols.
Policies, Procedures, and PKI.
Defense Message System 1.0.
California Independent Service Operator.
The Federal Bridge CA Project.
Appendix A: ASN.1 Primer.
Appendix B: Object Identifiers.