Public Key Infrastructure

All of the identification systems presented in the previous section share a common flaw: they allow people to create private relationships between themselves and a particular computer system, but they don't allow these relationships to be framed within the context of a larger society. They are all private identification systems, not public ones.

For example, say that Jonathan Marshall enrolls with a nationwide online service and creates an email account. When he creates the account, he gets a username, jonathan, and a password, deus451. Whenever Jonathan wishes to pick up his email, he uses his password to prove his identity. He might even create a private key to prove his identity, and give his online service a copy of his public key.

Now imagine that Jonathan loses his password. He can always go back to the nationwide service and create a new username, jmarshall, and a new password, excom3.0. But how does Jonathan convince the people he has been exchanging email with that jonathan and jmarshall are actually the same person?

One way that Jonathan could try to prove his identity would be for him to email his telephone number to his friends, and ask them to call him. This might work for people who had heard Jonathan's voice. Others, though, would have no way of knowing if Jonathan's voice really belonged to Jonathan or belonged to an imposter. This technique also wouldn't work if Jonathan was in the habit of posting in public forums: if there were thousands or tens of thousands of people who read what Jonathan wrote, there is simply no way that he could speak with them all individually.

Another way would be for Jonathan to appeal to a trusted third party to vouch for his identity. For example, he might scan his driver's license into his computer and post the image on his web site. The problem with this approach is that readers clicking into Jonathan's web site wouldn't actually be seeing his driver's license: they would be seeing a digital reproduction of the license. If the person using the jmarshall account were actually an imposter, that person could have taken his own driver's license, scanned it in, and used a program like PhotoShop to change the name to "Jonathan Marshall."

What Jonathan really wants is for his state to put a digital signature on his driver's license. (Some states are thinking about doing this; see Section 6.1.4.2 earlier in this chapter.) That digital signature would certify the contents of his driver's license: people downloading the image from the web would know that Jonathan's name or address had not been changed.

Unfortunately, the digitally signed credential is only half the problem. People corresponding with Jonathan will be able to look at the photograph on his driver's license and know what Jonathan Marshall actually looks like. But how will they know that jmarshall is really Jonathan Marshall? Instead of digitally signing Jonathan's photograph, the state should actually digitally sign his public key. Then Jonathan could sign all of his messages with his private key. Anybody wishing to verify that Jonathan's postings or email messages truly belong to him would simply have to get a copy of Jonathan's digitally signed public key and verify the signature that's on it.

Indeed, this is precisely the way that a public key infrastructure works. For more information, see the discussion of the cryptographic underpinnings of a PKI in Chapter 10.

6.2.1 Certification Authorities

A certification authority (CA) is an organization that issues public key certificates. Conceptually, these certificates look like cryptographically signed index cards. The certificates, signed by the certification authority's own private keys, contain the name of a person, that person's public key, a serial number, and other information, as shown in Figure 6.3. The certificate attests that a particular public key belongs to a particular individual or organization.

Figure 6.3. A schematic certification authority certificate.

There are many different ways that certification authorities can offer service: Internal CA

An organization can operate a CA to certify its own employees, their positions, and their levels of authority. Such a certification hierarchy could be used to control access to its internal resources or the flow of information. For example, every employee in an organization could create a key and be issued a certificate for that key detailed to the computer systems to which that employee should have access. Computers around the organization could then decide whether or not to grant an individual employee access based on the certification of his key. In this way, the business avoids the necessity of

distributing an access control list and a password file to all of its distributed computers.

Outsourced employee CA

A company might contract with an outside firm to provide certification services for its own employees, just as a company might contract with a photo lab to create identification cards.

Outsourced customer CA

A company might contract with an outside firm to operate a certification authority to be operated for the company's current or potential customers. By trusting in the outside firm's certification practices, the company would save the expense of creating its own procedures.

Trusted third-party CA

A company or a government can operate a CA that binds public keys with the legal names of individuals and businesses. Such a CA can be used to allow individuals with no prior relationship to establish each other's identity and engage in legal transactions.

To use the certificates issued by a CA, you need to have a copy of the CA's public key. Currently, public keys are being distributed prebundled in software packages such as web browsers and operating systems. Other

6.2.1.1 Revocation

Besides issuing certificates, CAs need a way of revoking them as well, because:

•

The key holder's private key may become compromised.

•

The CA may discover that it issued the certificate to the wrong person or entity.

•

The certificate may have been issued to grant access to a particular service, and the individual may have lost his authorization for that service.

•

The CA may have its systems compromised in such a way that someone has the ability to issue falsified certificates.

One way that has been proposed for handling revocations is the certificate revocation list (CRL). A CRL is a list of every certificate that has been revoked by the CA that has not yet expired for other reasons. Ideally, a CA issues a CRL at regular intervals. Besides listing certificates that have been revoked, the CRL states for how long it will be valid and where to get the next CRL.

CRLs are interesting in theory: they allow computers that are not connected to a network to determine if a certificate is valid or if it has been revoked. In practice, though, CRLs have a variety of problems:

•

CRLs tend to grow large very quickly.

•

There is a period between the time that a certificate is revoked and the time that the new CRL is distributed when a certificate appears to be valid but is not.

•

The information contained in CRLs can be used for traffic analysis.

Instead of CRLs, most production CAs will probably use real-time verification through the use of online database management systems connected to a network such as the Internet. These systems neatly dispense with the CRL problem, although they do require a network that is reliable and available.

An alternative suggested by Carl Ellison of Cybercash is simply to use certificates with very short expiration times - one to two minutes. In effect, this requires the person using the certificate to communicate with the CA before every transaction. In some cases, this may be more efficient than having the recipient of the certificate verify it with the CA.

6.2.1.2 Certification practices statement (CPS)

What does it mean to have a certified key? The answer to this question depends on who is doing the certification and what policies they are following. An internal CA that's run by a Fortune 500 company might certify that the person whose key is signed is an active employee. The hypothetical Cypherpunk Anonymous Key Signer, on the other hand, might sign any key that is sent to a particular electronic mail address. The certification practices statement (CPS) is a legal document CAs publish that describes their policies and procedures for issuing and revoking digital certificates. It answers the question, "What does it mean when this organization signs a key?"

CPS documents are designed to be read by humans, not by machines. It's possible that in the future the terms and conditions of CAs will become standardized enough that it will be possible for programs to automatically process CPS documents. A business might be willing to accept certification from a CA that guarantees certain minimum certification policies and a willingness to assume a certain amount of liability in the event that its certification policies are not followed - and provided that the CA is bonded by an appropriate bonding agency. Alternatively, laws or the market may encourage CAs to adopt standard policies throughout the industry, the same as credit card issuers have adopted more-or-less standard policies, choosing to distinguish themselves with different interest rates, service charges, and ancillary services.

6.2.2 The X.509 v3 Certificate

The X.509 v3 certificate is a popular standard for public key certificates. X.509 v3 certificates are widely used by many modern cryptographic protocols, including SSL. (X.509 certificates are not used by the PGP email encryption program versions 2.0 through 4.5, but it is possible that future versions of PGP will support X.509 v3.)

Each X.509 certificate contains a version number, serial number, identity information, algorithm-related information, and the signature of the issuing authority. Figure 6.4 shows the structure of an X.509 certificate.

Figure 6.4. The schematic structure of a typical X.509 certificate

The industry has adopted X.509 v3 certificates, rather than the original X.509 certificates, because the X.509 v3 standard allows arbitrary name/value pairs to be included in the standard certificate. These pairs can be used for many purposes. Microsoft's Internet Explorer will display some of the fields if you choose the "Properties" option while looking at a secure document. For example, Figure 6.5 shows the additional fields in the certificate issued by VeriSign for the Vineyard.NET, Inc., web site.

Figure 6.5. Some of the additional fields in the Vineyard.NET's X.509 v3 certificate, as displayed by Microsoft Internet Explorer

Figure 6.6 shows the fields from one of the earliest X.509 v3 certificates that was distributed on the Internet - the original RSA Secure Server Certification Authority. This certificate is a self-signed certificate, meaning that the signature on it was written by the RSA Secure Server Certification Authority private key. There is a copy inside every copy of Netscape Navigator and Microsoft Internet Explorer that has ever been distributed. You can also find a copy of this certificate at http://home.netscape.com/newsref/ref/rsa-server-ca.html.

Figure 6.6. The original RSA Secure Server Certification Authority certificate

As you can see, the certificate has a definite time period when it is valid. It identifies the name of the organization (O) and the country (C) the certificate identifies; the name of the organization (O) and the country (C) that issued the signature; the algorithm the signature uses; the public key; and, finally, the certificate's signature.

One of the interesting things about this certificate is that it is signed by the very organization (and public key) that it purports to identify. This is called a self-signed certificate . What it's saying, in effect, is this: "Here is my public key. It's mine. Trust me."

What makes it possible to trust this certificate is the social structure itself. The certificate comes inside programs like Netscape Navigator; if you can't trust the certificate, then you really can't trust Navigator, and you've got to be able to trust Navigator because that's the program that is verifying the other digital

certificates. You can also call up RSA Data Security (or now, VeriSign), read them the public key, and ask if it is really their public key. At the same time, though, you've got to trust somebody. 33

In document Web Security & Commerce pdf (Page 91-96)