7.3 Public Key Infrastructure

only for RuBoard - do not distribute or recompile

Public key infrastructure (PKI) is the system of digital certificates, certification authorities, tools, systems, and hardware that are used to deploy public key technology.

The word "public" in PKI has had an ambiguous history. Many of the early proponents of PKI envisioned a single PKI, operated by or for the government, which would provide state-certified certificates. In one vision, each person in the United States would be issued a certificate. These certificates could be used for digitally signing tax returns, for conducting online business, and for other official purposes. As acceptance increased, it was envisioned that PKI certificates would become the electronic equivalent of driver's licenses.

The public PKI was a grand vision, but so far it hasn't happened. Companies such as VeriSign have issued millions of certificates to verify the identity of individuals and organizations, and the keys to sign these certificates have been widely distributed. Some of these so-called trust hierarchies, such as the trust hierarchy used to certify web server certificates, are used by more than a hundred million people. But they are run by private businesses, and not by governments. The word "public" in PKI refers to public keys, rather than to the public at large.

To understand the issues involved in PKI today, it's helpful to look back at how we got where we are today.

7.3.1 Certification Authorities: Some History

When Netscape Communications started business in 1995, the World Wide Web was then beginning to take off. The most popular web browser was Mosaic, a free web browser distributed by the National Center for Supercomputing Applications (NCSA). There were a plethora of web servers, none of them tremendously popular, from CERN, NCSA, and others.

Netscape's grand business strategy was to make money by selling software that brought commerce to the Internet. Netscape's plan was to let people buy and sell things using credit cards. At the time, many banks and security experts argued that the Internet wasn't ready for credit card commerce because there was no way to protect credit card numbers as they traveled over the network. Fundamentally, there were two basic objections:

There was no readily apparent way to protect credit card numbers as they traveled over the network. Without suitable protection, a person at an Internet service provider would be able to eavesdrop on customers and learn their credit card numbers. This information could then be used for fraudulent purposes. Likewise, it was assumed that online banking, investing, and other activities would never blossom unless consumers could be assured that their transactions and personal information would not be revealed to third parties.
Consumers had no way to verify the identity of a shop on the network. A consumer might try to buy something from a web site, only to discover that the web site was actually run by credit card thieves!

To solve these problems, Netscape's engineers invented the Secure Sockets Layer protocol (SSL), which we described in Chapter 5. This protocol provided for a cryptographically secure communications channel between a web server and a web browser. To prevent site-spoofing, the SSL protocol included a digital certificate verification system. The SSL protocol would not operate unless the web browser was in communication with a site that had a digital certificate that was signed by an appropriate key.

Netscape put the icon of a little broken key at the bottom of its web browser. When the Netscape Navigator program reached a web site that used the SSL protocol, the key would be whole. If Navigator reached a web site that did not use the SSL protocol, the key would be broken. Consumers were told that sites that used SSL were "secure" and safe to use. Consumers were advised not to type credit card numbers or other personal information into sites that were not secure.

Thus, the original Navigator program had two ingenious systems for revenue protection and wealth creation:

Consumers were basically told not to do business with web sites that did not support the SSL protocol, and the only web server that supported SSL was the Netscape Commerce Server sold by Netscape.
Once a company purchased the Netscape Commerce Server, that company had to purchase signed digital certificates that were signed by the certification authority whose key was built into the Netscape browser.

Rather than set up its own certification authority, which could have been seen by some companies as anticompetitive, Netscape turned to RSA Data Security, which had supplied the public key technology software on which Navigator was based. For several years RSA had been running its own CA called RSA Certification Services. This CA existed to support other protocols that require CAs, such as Privacy Enhanced Mail (PEM). RSA was more than happy to issue certificates for Netscape servers as well.

Microsoft broke Netscape's monopoly on cryptographically-enabled web servers when it released the Microsoft Internet Information Server (IIS). The monopoly was further broken when Eric Young created an open source implementation of the SSL protocol called SSLeay. Suddenly, there were many alternatives for organizations seeking to offer cryptographically-enabled web servers, and Netscape's products quickly lost market share.^[9]

^[9] We don't mean to imply that this was the reason that Netscape lost market share.

By all indications, the same sort of competition should have taken hold in the field of certification authorities, but it did not, in part because RSA Data Security aggressively enforced its patent rights. Without RSA's approval, CAs could only do business outside the U.S.

In 1995, RSA spun out its certificate services division to a new company called VeriSign. Many people complained that they did not want to be forced to purchase certificates from a single vendor, so Netscape, and later Microsoft, made provisions for supporting multiple CAs in its web browser:

Netscape Navigator Version 1.0 contained a CA certificate for a single authority, the Secure Server Certification Authority, operated by RSA Data Security, Inc.
Netscape Navigator Version 2.0 still came with support for only a single CA, but it allowed other CAs to be loaded with the user's permission.
Netscape Navigator Version 3.0 came preloaded with certificates for 16 CAs at 11 companies (AT&T, BBN, Canada Post Corporation, CommerceNet, GTE CyberTrust, Keywitness, MCI Mail, RSA, Thawte, U.S. Postal Service, and VeriSign.) The program also contained a user interface for viewing the currently loaded certificates, deleting certificates that were already resident, or adding more.
Internet Explorer 3.0 shipped with a subset of the Navigator 3.0 certificates (AT&T, Keywitness, MCI Mail, RSA, and VeriSign).

Although all of the seeds were in place for a competitive market, in practice that market never materialized. VeriSign quickly grew to be the primary source for SSL digital certificates on the Internet. Despite having their keys bundled in Navigator, AT&T, BBN, Canada Post, and others never offered commercial CA services. VeriSign's primary competitor for server certificates was the South African company called Thwate Holdings, which (as noted earlier) was eventually purchased by VeriSign.

Today, Internet Explorer and Netscape Navigator are shipped with a large number of built-in CA certificates. Nevertheless, VeriSign remains the dominant source of server certificates on the Internet today.

7.3.2 Internet Explorer Preinstalled Certificates

Both Netscape Navigator and Microsoft Internet Explorer come with a set of preinstalled certificates. Current versions of these programs allow you to view and modify these lists.

You can view the certificates that are preinstalled in Internet Explorer by following these steps:

Open the "Internet Options" control panel.
Select the "Content" tab.
Click on the button that says "Certificates..."

Internet Explorer will now display the "Certificates" panel (see Figure 7-15). The program supports a wide number of certificate types, including:

Personal

Certificates issued to a user of the computer. These certificates are used to identify the user and to facilitate the exchange of encrypted electronic mail.

No personal certificates are provided with Internet Explorer by default.

Other People

Certificates issued to other people that the computer's user corresponds with. These certificates are used to verify signatures on electronic mail and to encrypt email that is destined for the other people.

No "Other People" certificates are provided with Internet Explorer by default.

Intermediate Certification Authorities

Intermediate Certification Authorities certificates are CA certificates that are bundled with Internet Explorer, but that are not trusted.

Internet Explorer 5.0 provides for a number of Intermediate Certification Authorities, including:

MS SGC Authority
Root Agency
SecureNET CA SGC Root
Thawte Premium Server CA
Thawte Server CA
UTN-DATAC
VeriSign Class 1 Public Primary Certification Authority
VeriSign Class 2 Public Primary Certification Authority
VeriSign Class 3 Public Primary Certification Authority

Trusted Root Certification Authorities

These self-signed certificates are the roots of trust hierarchies. Trusted Root Certification Authorities are trusted, although Internet Explorer's interface allows you to control which certificates are trusted for which purposes.

Certificates are provided for a large number of Trusted Root Certification Authorities, as shown in Table 7-1.

Figure 7-15. Internet Explorer comes with a set of built-in CA certificates.

Table 7-1. Certification authority keys bundled with Internet Explorer 5.0
Certification authority	Country	# of certificates
ABA.ECOM, Inc.	U.S.	1
Autoridad Certificadora de la Asociacion Nacional del Notariado Mexicano	Mexico	1
Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana	Mexico	1
Baltimore EZ (Digital Signature Trust)	U.S.	1
Belgacom E-Trust	Belgium	1
C&W HKT SecureNet	Hong Kong	4
CA 1 (ViaCode)	Great Britain	1
Certiposte	France	2
Certisign Certificadora Digital Ltda.	Brazil	4
Certplus	France	4
Deutsche Telekom	Germany	2
Digital Signature Trust	U.S.	6
Entrust.net	U.S.	1
Equifax Secure Certification Authority	U.S.	4
EUnet International	N/A	1
FESTE	Spain	2
First Data Digital Certificates	U.S.	1
FNMT	Spain	1
GlobalSign	Belgium	1
GTE CyberTrust	U.S.	3
IPS Seguridad	Spain	1
Microsoft	U.S.	3
National Retail Federation (Digital Signature Trust)	U.S.	1
NetLock Tanusitvanykiado	Hungary	3
PTT Post	Netherlands	1
Saunalahden Serveri Oy	Finland	2
Secure Server Certification Authority, RSA Data Security	U.S.	1
SecureNet	Australia	4
SecureSign, Japan Certification Services, Inc.	Japan	3
Servicios de Certificacion, Servicios Electronicos, Administracion Nacional de Correos	Uruguay	1
SIA S.p.A.	Italy	2
Swisskey AG	Switzerland	1
TC TrustCenter for Security in Data Networks GmbH	Germany	5
Thawte Consulting	South Africa	6
United Parcel Service (Digital Secure Trust)	U.S.	1
UserTrust	U.S.	5
ValiCert Validation Authority	U.S.	3
VeriSign	U.S.	21
Xcert EZ (Digital Secure Trust)	U.S.	1

That's 107 certificates that are distributed with Internet Explorer, the vast majority of which are used to certify email messages and web sites. Each of these certificates is given equal standing by IE and that means users in the United States end up putting the same amount of trust into certificates issued by the billion-dollar corporation VeriSign and by the Servicios de Certificacion, Servicios Electronicos, Administracion Nacional de Correos in Uruguay.

According to Microsoft, the process for organizations to get their certificates bundled with Internet Explorer has changed over the years. In a personal communication that we received in April 2001, the process was described to us as follows:

A CA submits its request to the alias casubmit@microsoft.com. They should include two contacts (name, email, telephone) from the company, the company address information, and how many roots they would like to submit. Somebody at Microsoft follows up with them from there. We look at several factors before accepting a root:

1. What is the root used for? Obviously privately used roots are not interesting to include in Microsoft products.

2. Has the CA been audited? We look to see if an appropriate third party has audited the CA. This audit would look at their root key generation, CPS, and operational controls.

3. Are the roots long lived? Roots only valid for a few years are not suitable for our program.

7.3.3 Netscape Navigator Preinstalled Certificates

Like Internet Explorer, Netscape Navigator is delivered with a large number of preinstalled certificates.

To view or edit the certificates that are built into Netscape Navigator 6.0, display the Netscape Security Manager using these steps under Windows:

Select the "Tasks" menu.
Select "Privacy and Security".
Select "Security Manager".
Click on the "Certificates" tab.
Select "Authorities".

This will display the Netscape Personal Security Manager (Figure 7-14).

On a Macintosh:

Select the "Edit" menu.
Select "Preferences".
Select "Privacy and Security" and expand its sublist.
Select "Certificates".
Select "Manage Certificates".

This will display the Netscape Certificate manager.

All of the certificates that are bundled into Netscape Navigator 6.0 are shown in Table 7-2.

Table 7-2. Certification authority keys bundled with Netscape Navigator 6.0
Certification authority	Country	# of certificates
ABA.ECOM, Inc	U.S.	1
AddTrust	Sweden	4
American Express	U.S.	2
Baltimore CyberTrust	U.S.	3
BankEngine	Canada	1
BelSign Object Publishing CA (Since renamed GlobalSign)	Brussels,	4
beTRUSTed	"WW"^[10]	1
CertEngine	Canada	1
Deutsche Telekom	Germany	1
Digital Signature Trust	U.S.	4
E-Certify	Canada	2
Entrust.net	U.S.	3
Equifax Secure Certification Authority	U.S.	5
FortEngine	Canada	1
GlobalSign	Belgium	5
GTE CyberTrust	U.S.	5
MailEngine	Canada	1
TC TrustCenter	Germany	5
Thawte Consulting	South Africa	6
TraderEngine	Canada	1
United States Postal Service	U.S.	1
UserTrust	U.S.	5
ValiCert Validation Authority	U.S.	4
VeriSign (and RSA)	U.S.	18
Visa International	U.S.	5
Xcert (Digital Secure Trust)	U.S.	5

^[10] This is what the key says; it does not correspond to any particular country code.

7.3.4 Multiple Certificates for a Single CA

Several companies have more than one CA certificate in the CA list. VeriSign has the most: 21 different certificates (22 if you count the RSA Secure Server Certification Authority.) The idea is to use signatures by different private keys to denote different levels of trust and authentication.

The evolution of VeriSign's practices is shown in Table 7-3 (for 1996) and Table 7-4 (for 2001). In 1996, VeriSign offered only four kinds of certificates three for individuals, and one for "Secure Servers" (Table 7-3).

Table 7-3. VeriSign certificates in 1996
Certificate name	Certificate type	Certification practice	Cost	Liability protection
Class 1	Client^[11]	VeriSign assures that the user can receive email at the given address and that no other certificate for the email address has been issued.	Free (nominally $9.95/year)	$100
Class 2	Client	VeriSign assures the identity of a digital ID holder through online identity verification against a consumer database.	$19.95/year	$5,000
Class 3	Client	VeriSign validates the entity applying for the certificate using background checks and investigative services.	$290/first year; $75/renewal	$100K
Secure Server	Server	VeriSign validates the entity applying for the certificate using background checks and investigative services.	$290/first year; $75/renewal	$100K

^[11] See Chapter 21 for a description of this type of certificate.

VeriSign certificates come with liability protection in the form of VeriSign's "NetSure Protection." Backed by Lloyd's of London, NetSure is not an insurance policy. Instead, it is "an extended warranty program that protects VeriSign Server ID customers against economic loss resulting from the theft, corruption, impersonation, or loss of use of a certificate." VeriSign was the first company to offer this kind of protection on its certificates. But the warranty is somewhat limited, because the NetSure program has a per-certificate limit, rather than a per-transaction limit. Presented with a Netscape Secure Site Pro certificate, a merchant might reasonably assume that the certificate has $250,000 of insurance and feel comfortable engaging in a $1000 transaction. But if that same certificate were used to commit 1000 fraudulent transactions on the same day, then each merchant might ultimately be able to recover only $250 in compensation. Although the warranty program is commendable, the problem is that, unlike liability insurance policies, an insured certificate can be used in thousands of transactions within the space of a few seconds. When a car is insured, it can only be involved in one accident at a time.

As of September 2001, no claims had been presented to VeriSign under the program.

Table 7-4. VeriSign certificates in 2001
Certificate name	Certificate type	Strength^[12]	Certification practice	Cost	NetSure protection
Class 1 Digital ID	Client^[13]	N/A	VeriSign assures that the user can receive email at the given address.	$14.95 per year	$1000
Secure Site	Server	40-bit	VeriSign validates the entity applying for the certificate by verifying the organization's address using Dunn & Bradstreet.	$349 per year	$100K
Secure Site Pro	Server	128-bit	VeriSign validates the entity applying for the certificate by verifying the organization's address using Dunn & Bradstreet.	$895	$250K
Commerce Site	Server	40-bit	VeriSign validates the entity applying for the certificate by verifying the organization's address using Dunn & Bradstreet. Price includes a performance audit of the web site from two cities.	$995	$100K
Commerce Site Pro	Server	128-bit	VeriSign validates the entity applying for the certificate by verifying the organization's address using Dunn & Bradstreet. Price includes a performance audit of the web site from ten cities.	$1495	$250K
OnSite for ServerIDs	Intermediate CA	40-bit or 128-bit	After validating an organization and negotiating a fee, VeriSign issues a certificate that allows the organization to issue its own certificates for SSL servers throughout its own enterprise.	Negotiated

^[12] SSL certificates can specify the maximum allowable cryptographic strength to be used by the server. This provision was originally created to assist with the enforcement of U.S. export regulations. Today, this provision is used by VeriSign to extract higher revenue from organizations that are willing to pay for stronger encryption.

^[13] See Chapter 22 for a description of this type of certificate.

7.3.5 Shortcomings of Today's CAs

It's unfortunate, but if you look closely into the root certificates that are bundled with Internet Explorer and Netscape Navigator, you'll see that there are significant inconsistencies and quality control problems with today's CAs.

7.3.5.1 Lack of permanence for Certificate Policies field

Internet Explorer's Certificate panel allows you to automatically open the web page that is associated with the certification practices statement for each of the certificates that is registered. This field is indicated as a URL in a field called "Certificate Policies" in the X.509 v3 certificate.

Here is the Certificate Policies field from the Autoridad Certificadora de la Asociacion Nacional del Notariado Mexicano, A.C. certificate that is bundled with Internet Explorer 5.0:

[1]Certificate Policy:      PolicyIdentifier=2.16.840.1.113733.1.7.1.1      [1,1]Policy Qualifier Info:           Policy Qualifier Id=CPS           Qualifier:                www.NotariadoMexicano.org.mx/RCD/dpc

To view the CPS referenced in this certificate, follow these steps:

Select the certificate in the Certificate panel.
Click the "View" button.
Click the button that says "Issuer Statement." As Figure 7-16 shows, the General panel of the Certificate window on Netscape Navigator displays general information about a certificate. In this figure, the panel is displaying information for the self-signed certificate issued by the Autoridad Certificadora del Colegio Nacional de Corredurla Publica Mexicana Certification Authority. Because this certificate comes preloaded in Internet Explorer, Microsoft's operating system affords the same level of trust to these certificates as to those issued by all the other CAs, such as VeriSign. This may or may not be a problem; see Figure 7-17.

Figure 7-16. The General panel of Internet Explorer's Certificate window shows general information abut a certificate

Figure 7-17. All CAs are not created equal. The home page of the web server for the Colegio Nacional de Correduria Publica Mexicana, A.C. reveals that the site is "en construcci n" and has been, apparently, for more than a year. The URL for the CA's certification practies statement does not exist. Yet this CA's key is fully trusted by Internet Explorer.

It is very important for a CA to maintain a web page at every URL that is listed in every certificate that it has ever issued. If these URLs move, links should be left in their place. If a CA changes its CPS, then it must archive each CPS at a unique URL. These links must remain accessible for the lifetime of any signed certificate that references the CPS. This is because the legal meaning of the certificate cannot be determined without reading the certificate practices statement. Furthermore, because it is possible that the meaning of a signature might be questioned many years after the signature is created, the URLs should probably remain active for a period of at least 20 years.

Unfortunately, as Figure 7-17 shows, many of the CA certificates point to CPSs that are no longer accessible. Here, the self-signed certificate distributed with Internet Explorer 5.0 for the Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana, A.C. is valid from June 29, 1999 until June 29, 2009. The certificate claims that the certificate practices statement for this key is located at http://www.correduriapublica.org.mx/. Nevertheless, by April 2001 the URL for that CPS was not accessible.

7.3.5.2 Inconsistencies for "Subject" and "Issuer" fields

The CA certificates that are bundled into Netscape Navigator and Internet Explorer are supposed to be the basis for the world's e-commerce infrastructure and legally binding agreements. Complicating this goal is the fact that there is a huge variation in the ways that the certificate fields are being used by different organizations.

For example, the Subject field of the ValiCert CA certificate has these qualifiers:

E = info@valicert.com CN = http://www.valicert.com/ OU = ValiCert Class 1 Policy Validation Authority O = ValiCert, Inc. L = ValiCert Validation Network

In the same version of Internet Explorer, there is a VeriSign certificate for providing digitally-signed time that has a completely different set of qualifiers in the Subject field:

OU = NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc. OU = VeriSign Time Stamping Service Root OU = VeriSign, Inc. O = VeriSign Trust Network

There's a certificate for PTT Post in the Netherlands with an even stranger Subject field:

0.9.2342.19200300.100.1.3 = ca@ptt-post.nl CN = PTT Post Root CA OU = KeyMail O = PTT Post C = NL

One of the better examples of Subject qualifiers can be found in the VeriSign Class 4 certificate that is distributed with Internet Explorer:

OU = VeriSign Trust Network OU = (c) 1998 VeriSign, Inc. - For authorized use only OU = Class 4 Public Primary Certification Authority - G2 O = VeriSign, Inc. C = US

At the other end of the spectrum is SecureNet in Australia, which distributes four certificates with Internet Explorer. The company's "CA Class A" certificate is extraordinarily simple. It is used for certifying email and web server SSL connections. The certificate is valid June 30, 1999 until October 16, 2009. There is no CPS that is referenced in the certificate's fields. And the Subject field has only two values:

O = SecureNet CA Class B C = au

Consistency in the use of the Distinguished Name and other fields is vital if certificates are to be processed in a programmatic way with software. Without this consistency, certificates would need to be visually inspected by individuals who are trained to understand all of the different styles and formats that legitimate names can have, so that valid certificates can be distinguished from rogue ones.

7.3.5.3 Unrealistic expiration dates

Early versions of the Netscape Navigator web browser were distributed with CA certificates that had expiration dates between December 25, 1999 and December 31, 1999. These products were in use far longer than anybody anticipated. When the end of 1999 rolled around, many of the products with these old CA certificates inside them simply stopped working. Although it should have been possible to simply download new certificates, users were advised to upgrade their entire applications because of other security problems with these early products. Many users were not happy that the software they had been depending on suddenly stopped working.

As a result of this experience, many CAs have decided to err in the other direction. They have started distributing CA certificates with unrealistically long expiration times. All of the certificates distributed with Internet Explorer 5.0 are 1024-bit RSA certificates, yet more than half of these certificates have expiration dates after January 1, 2019! As Figure 7-18 shows, VeriSign distributes eight certificates with Internet Explorer 5.5 that have expiration dates in the year 2028! Many cryptographers believe that 1024-bit RSA will not be a secure encryption system at that point in the future.

Figure 7-18. VeriSign distributes many keys with Internet Explorer 5.5 that have unrealistically late expiration dates

only for RuBoard - do not distribute or recompile

7.3 Public Key Infrastructure