A certification authority (CA) is any organization that issues digital certificates.
Any individual or organization can be a certification authority: being a CA simply means that the individual or organization signs certificates with a public key. A CA can impose standards before it signs a key; in the case of a university, it would probably verify that the key that it was about to sign really belonged to a bona fide student. Another CA might not have any standards at all. The world’s largest CA, VeriSign, issues several different kinds of certificates. VeriSign signs certificates under its VeriSign Trust Network (VTN) for public use; the company also issues certificates for use within corporations. The lowest level of certificates issued by VTN have no assurance; the highest levels come with the promise that VTN attempted to establish the identity of the key holder before the certificate was issued.
Conceptually, a CA’s certificate looks like a cryptographically signed index card. The certificates, signed by the certification authority’s own private key, contain the name of the CA, that CA’s public key, a serial number, and other information, as shown in Figure 7-7. To date, most certificates are a promise by the CA that a particular public key belongs to a particular individual or organization. But certificates can also be used for assertions. For example, the Commonwealth of Massachusetts could issue certificates saying that an individual is a licensed attorney in the Commonwealth. There are many different ways that a certification authority can offer service:
- Internal CA
An organization can operate a CA to certify its own employees. Certificates issued by an internal CA might certify an individual’s name, position, and level of authority. These certificates could be used within the organization to control access to internal resources or the flow of information. Such an internal CA would be the basis of the organization’s public key infrastructure. (See Section 7.3 later in this chapter.)
For example, a computer system used for purchasing could be set up so that any employee presenting a valid certificate saying that the employee was in the Purchasing Department would be given access. Internal CAs allow organizations to centralize access control to a large number of systems without having to distribute usernames, passwords, and access control lists throughout the enterprise. These systems can also implement so-called single sign-on, so that an employee needs to log into his or her computer only once, and then have access to the entire enterprise.
Companies can also operate internal CAs that issue certificates to customers. For example, some brokerages have required that their customers obtain certificates before they are allowed to execute high value trades over the Internet.
- Outsourced employee CA
An organization might want to partake in the benefits of using digital certificates, but not have the technical ability to run its own certificate servers. Such an organization could contract with an outside firm to provide certification services for its own employees, exactly 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 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. Certificates issued by such a CA would be exactly analogous to driver’s licenses and identity cards issued by a state’s Department of Motor Vehicles.
Before you can use the certificates issued by a CA, you need to have a copy of the CA’s public key. Public keys are distributed on certificates of their own. Currently, most of these certificates are prebundled in web browsers and operating systems. CA public keys can be added manually by the end user.
Clearly, CAs that do not have their keys prebundled are at a disadvantage. Although Microsoft and Netscape have now opened up their browsers to any CA that can meet certain auditing requirements, the original web browsers were distributed with a small number of carefully selected CA keys. The bundling of these keys was a tremendous advantage to these CAs and a barrier to others.
On December 19, 1999, VeriSign, the world’s largest CA, bought Thawte Holdings, a South African corporation, for $575 million dollars of VeriSign stock.[88] In completing this transaction, VeriSign purchased its only significant competitor in the lucrative market of server certificates—the only other corporation in the world that was both offering CA services for SSL servers and that had succeeded in getting its certificates bundled with popular web browsers.[89]
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 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.
Although certification authorities can issue any kind of certificate, in practice the vast majority of CAs issue certificates that follow the X.509 v3 standard. Likewise, most cryptographic programs and protocols, including SSL, are only designed to use X.509 v3 certificates. The only notable exception to this is PGP, which uses its own certificate format, although recent versions support reading some X.509 certificates. (The Secure Shell (ssh) program does not actually use certificates, but instead relies on the registration of public keys.)
Each X.509 certificate contains a version number, a serial number, identity information, algorithm-related information, and the signature of the issuing authority. Figure 7-8 shows the structure of an X.509 certificate.
The industry 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 and allow the uses of certificates to be expanded without changing the underlying protocol.
You can use Microsoft’s Internet Explorer to display information about an X.509 v3 certificate. For example, if you are viewing a web page that was downloaded using the “https:” protocol, you can use Internet Explorer to show you the server’s certificate. To view the certificates, choose the “Properties” option from the File menu while looking at a document that was downloaded using “https:” and click on the “Certificate” button.
Figure 7-9 shows the “General” certificate properties for two certificates downloaded from the web. The first is for the web site https://www.vineyard.net/, which belongs to Vineyard.NET, Inc. The second is for the web site https://wfbdirect.wellsfargo.com/, which is for Wells Fargo’s Wells Fargo Bank Direct service. Overall, the “General” properties page is not terribly useful. Instead of listing the name of the organization that was issued the certificate, it merely shows the DNS address. The page doesn’t even show the name of the organization that issued the certificate!
Figure 7-9. The “General” certificate properties, as viewed by Internet Explorer, for certificates downloaded from Vineyard.NET and Wells Fargo.
More information can be found on Internet Explorer’s “Details” page, which is shown in Figure 7-10. Each of these certificates has a definite time period when it is valid, a “Subject,” the certificate’s public key, the “Thumbprint algorithm,” and the “Thumbprint.” Here, the word thumbprint is used as a synonym for message digest.
The Subject field is further divided into other fields:
Figure 7-10. Some of the additional fields in the X.509 v3 certificates belonging to Vineyard.NET and Wells Fargo, as displayed by Microsoft Internet Explorer.
Field Code | Meaning |
|---|---|
CN | Common Name (for SSL certificates, the Common Name should be the DNS address of the server) |
OU | Organizational Unit |
O | Organization |
L | Location |
S | State |
C | Country |
If you look carefully at the OU field of the Vineyard.NET certificate, you will notice that instead of indicating the organizational unit of Vineyard.NET, the OU field contains the URL of VeriSign’s Relaying Party Agreement (RPA). VeriSign places the URL of the RPA in this field because not all client programs can display the certificate policies extension fields where this information would normally be placed.
Every browser can determine that these certificates are valid because each certificate is signed with a private key that matches a public key certificate that it trusts. The steps from a downloaded certificate to a certificate that is trusted is called the certification path. You can view the path using Internet Explorer’s “Certificate Path” panel, as shown in Figure 7-11. The Certificate Path is similar to PGP’s Web of Trust model, except that trust starts at the top and works its way down: if you trust a CA, then you automatically trust any keys that the CA signs. If that CA signs a key that is used to sign a third key, then you automatically trust that third key as well. This is called a certificate chain.
Figure 7-11. The Certificate Path panel for the certificates belonging to Vineyard.NET and Wells Fargo, as displayed by Microsoft Internet Explorer.
Figure 7-12 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. This key was inside every copy of Netscape Navigator and Microsoft Internet Explorer that was distributed until January 1, 2000. This single key was a critical factor in the financial success of VeriSign’s digital certificate business, because it was this key that made it possible for VeriSign to issue site certificates. For a more detailed discussion of VeriSign’s history, see Section 7.3.1 later in this chapter.
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 such as Internet Explorer and Netscape Navigator. The people who created that software decided that the certificate was trustworthy; if you can’t trust their judgment, then you really shouldn’t trust Explorer or Navigator, and you’ve got to be able to trust those programs because they are the programs that you are using for verifying the other digital certificates. If you wanted further verification you could go to VeriSign’s web site and verify the certificate or, if you are even more untrusting, you could call up VeriSign’s technical support department, read them the public key, and ask the person if the key is really VeriSign’s. Of course, you might not believe that the person who answered the phone really worked for Verisign and knew what they were talking about, but if you want to use computers, at some point you’ve got to trust somebody. (Trust us on this!)[90] Computers are so complicated that you simply cannot create your own microchips, circuit boards, operating systems, and application software necessary for a secure computing environment.
In point of fact, however, most Internet users are unaware of the trust that they are placing in their software and the certificates they contain. All they know is that the software works (or at least seems to work). In fact, the security provided by public key cryptography is significantly greater than the security of the underlying operating systems.
There are four primary types of digital certificates in use on the Internet today:
- Certification authority certificates
These certificates contain the public keys of CAs and either the name of the CA or the name of the particular service being certified. These certificates are typically self-signed—that is, signed with the CA’s own private key. CAs can also cross-certify, or sign each other’s master keys. What such cross-certification actually means is an open question. Microsoft Windows, Microsoft Internet Explorer, and Netscape Navigator are all shipped with more than a dozen different CA certificates.
- Server certificates
These certificates contain the public key of an SSL server, the name of the organization that runs the server, the DNS name of the server, and the server’s public key. Every cryptographically-enabled web server on the Internet must be equipped with a server certificate for the SSL encryption protocol to function properly. Although the originally stated purpose of these certificates was to allow consumers to determine the identity of web servers and to prevent man-in-the-middle attacks, in practice server certificates are not used for this purpose.
- Personal certificates
These certificates contain an individual’s name and the individual’s public key. They can have other information as well, such as the individual’s email address, postal address, birth date, and other identifying information.
Some banks and investment houses issue digital certificates to their depositors. The certificates are typically kept on the depositor’s home computer and provide an extra level of assurance when the subscriber attempts to access his or her accounts.
Many corporations issue digital certificates to their employees. Each web server that belongs to the organization can then simply grant access to anyone who has a valid certificate, without having to be equipped with an entire employee roster. This also frees employees from having to remember many individual usernames and passwords. Personal certificates are also required for users of the S/MIME email encryption protocol (described in Chapter 4).
Personal certificates are a substantially more secure way of having people identify themselves on the Internet than the alternative: usernames and passwords. Personal certificates are described in detail in Chapter 6 and Chapter 22.
- Software publisher certificates
These certificates are used to verify the signatures on software that is distributed, such as ActiveX components and downloadable executables. Every copy of recent Windows operating systems is distributed with a number of software publisher certificates that can be used to validate the signatures on Windows applications (see Figure 7-13).
Publisher certificates and code signing are described in Chapter 22.
Figure 7-13. Digital signatures and software publisher certificates are used to verify the integrity and authorship of software that is downloaded over the Internet.
And this is only the beginning! Many security professionals believe that digital certificates will eventually be widely used throughout the Internet, computing, and society as a whole. Some proposed uses of digital certificates include the following:
For consumers, digital certificates could be used to prove membership in an organization or the right to a legal privilege without revealing the consumer’s name. For example, college-aged consumers could have digital certificates stating that they are over the age of 21. Students could then use these certificates to purchase alcohol without being forced to reveal their names.
Age-proving digital certificates could also be used to control access to pornography and other information on the Internet that is legally restricted from minors.
You might use digital certificates to eliminate junk mail from your email inbox. To do this, you would program your email system to reject all mail that is not digitally signed.
Public keys and digital certificates will increasingly be used for signing contracts over the Internet.
Digital certificates might be used as the authentication infrastructure for a national identity card.
But remember: the fact that people can authenticate themselves using certificates does not alone prove that they are who they claim to be. It only proves that they possess a secret key that has been signed by an appropriate certification authority.
Figure 7-14. Netscape Navigator 6.0’s Security Manager allows you to specify for what purpose a certificate will be used.
Digital certificates represent a threat to the privacy of their users. When you flash a driver’s license at a bar to prove your age, the bartender doesn’t copy down your name, address, birthday, height, weight, and whether you need glasses. But if you present a “driver’s license digital certificate” to a web site to download some information, the web site would get all of the information and more. In many jurisdictions, an organization that obtained this information in the course of business would be free to do whatever it wished with the data. For example, the web site could use the height and weight information to compile a list of overweight individuals and then sell this list to an online merchant that marketed dieting aids.
One way to minimize the privacy threat is to have a lot of private/public key pairs and a lot of digital certificates. This approach doesn’t work in practice, however: no reputable certification authority would issue a certificate saying “This person is over 21” without tying that certificate to the individual’s name. Otherwise, the individual could give the certificate and the corresponding private key away without any repercussions.
A better way to minimize the privacy threat is by using minimal disclosure certificates . These certificates allow the holder to selectively reveal specific facts that are on a certificate without revealing others. A woman who wanted to gain access to a web site for a cancer survivors group might use minimal disclosure certificates to prove to the web site that she was a woman over 21 who had breast cancer without revealing her name or address. Minimal disclosure certificates were invented by the mathematician Stefan Brands and exclusively licensed in February 2000 to the Canadian corporation Zero Knowledge Systems.[91]
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.
The need for effective revocation mechanisms was made particularly clear in March 2001, when Microsoft announced in a security advisory that VeriSign had issued two certificates, on January 29 and 30, “to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is “Microsoft Corporation.” Microsoft went on to note that “the ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run.”[92]
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 how long it will be valid and where to get the next CRL.
Current practice is that X.509 v3 certificates should contain a field called the CRL distribution point (CDP). In theory, a program that wishes to verify if a certificate has been revoked should be able to download a CRL from the CDP to determine if the certificate has been revoked. As most certificates will be issued by a small number of CAs, it is reasonable to assume that a program might download a new CRL every day or every hour, and then cache this list for successive lookups.
CRLs and CDPs are interesting technology; 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, this technology has a variety of problems:
If a CA is very popular, it is likely that the CRLs will grow very large. VeriSign’s 900K CRL for its SSL server certificates can take more than 20 minutes to download over a dialup connection.
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.
Many programs do not properly implement CRLs and CDPs.
In the case of the fraudulently-issued Microsoft certificate, the bogus certificate was revoked and listed in VeriSign’s CRL. Unfortunately, the certificates that VeriSign issued did not contain valid CDPs. (According to VeriSign, CDPs are not present in Authenticode certificates because of a bug in the implementation of Authenticode distributed with Internet Explorer 3.02.) Without the CDP, a program that attempted to verify the authenticity of the fraudulently-issued certificates does not know where to find the CRL on which the certificates were listed.
After the fraudulently-issued certificates were discovered, Microsoft attempted to resolve the problem by issuing operating system patch 28888. This patch contained:
A CRL that listed the two certificates VeriSign had mistakenly issued.
An additional revocation handler that causes Internet Explorer to consider the local CRL when evaluating the authenticity of certificates.
As the Microsoft experience shows, when you choose to trust a certification authority, you really do make yourself vulnerable to poor decisions that the CA may make or operating practices that it may have.
An alternative to CRLs is to use real-time validation of certificates. These systems consult an online database operated by the certification authority every time the authenticity of a certificate needs to be validated. Two technologies actively under development to aid real-time validation are the XML Key Management Specification and the Security Assertions Markup Language (SAML).
Real-time certification validation systems neatly dispense with the CRL problem, although they do require a network that is reliable and available. The primary problem with real-time validation is one of scale. As there are more and more users of certificates, the validation servers need to be faster and faster to serve the larger user community.
Furthermore real-time systems are vulnerable to denial of service (DoS) attacks. If it is not possible for a business to connect to the revocation server, what should be done with a certificate—trust it or discard it? If the default is to trust it, fraud can be committed by flooding the revocation server so as to make it unresponsive while a revoked certificate is used. If the default is to reject requests when the revocation server is unreachable, then it is possible to cause all transactions to be rejected using a DoS attack, thus damaging the reputation of the business.
An alternative is simply to use certificates with very short expiration times—perhaps as short as one to two minutes. In effect, this requires the person using the certificate to communicate with the CA before every transaction to get a new certificate. In many cases, this method may be more efficient than having the recipient of the certificate verify it with the CA.
[89] Other corporations had succeeded in having their certificates bundled with early versions of Netscape Navigator or Internet Explorer, but never offered service to the general public. Even today, the Microsoft and Netscape browsers are distributed with a large number of CA keys belonging to apparently defunct projects.
[90] For more information about the trust problem, see Chapter 27, “Who Do You Trust?” of Practical Unix & Internet Security (O’Reilly).