Commentary by Mark Wahl
Organizing principles for identity systems:
The trust is out there: the mythology of PKI (2006/9/18)
The term myth, when used in technology engineering discussions, often has a pejorative connotation: it's a myth implies a folk belief is no longer tenable in the face of available evidence. The classic example is the mythical man-month. The formal definition of a myth, however, is neutral: a myth is a story. Frequently, the stories that become myths do so because they offer explanations: they link meanings to events and circumstances that lack an obvious explanation or that would otherwise not have an accepted meaning. That the explanation offered by the myth be plausible, realistic, or the best possibility among competing explanations, however, is not necessary for a story to be categorized a myth: it is only necessary that at some point in time, the story was believed by some people to be true.
Public key infrastructure, besides a technology space, also appears as a modern mythology. It has an integrated collection of myths, stories about how Internet security operates that provide meanings and interpretations on what users should expect from Internet security.
(Certainly the term myth has already been widely applied to PKI, although typically only with its negative connotation. For example, Roger Clarke, in PKI and Privacy, wrote in 2000 that the conventional PKI industry was based on a mythology as it had many deficiencies, including that "in order to have trust in the party you are transacting with, you are expected to have trust in organisations you have no relationship with at all". Anish Bhimani, in a Information Security magazine article PKI: be careful what you wish for, mentions the "grand myth" of the single enterprise certificate: that an organization can use a single CA for all its purposes. And iang.org, in PKI considered harmful highlights many concerns, as do numerous other papers.)
As with other social constructs, PKI works, in part, because people believe it works. And in many of its technical aspects, it actually does work, thanks to the hard work of cryptographers, standards committees, implementors, businesspeople such as
and
, and other mythic figures.
In general, for those who are not interested in its inner workings and merely want to have security just work, PKI offers up explanations, defining notoriously slippery terms like trust and identity and offering technology solutions to provide these services.
One of the key myths, or simplifying assumptions, in current PKI deployments is the trusted roots. Originally, X.509 did not incorporate this concept, and building a trust path from A to B involved following a chain of cross-certificates from the CA issuing the certificate to A to the CA issuing the certificate to B. This was impractical, so a hierarchical certificate path approach was proposed for PKI deployments on the Internet, which also faced difficulty as the namespace for X.509, distinguished names, did not match the namespace for Internet applications, email addresses and domain names. This was fixed with the introduction of X.509v3 with its certificate extensions and the idea that a packaged client application, such as a web browser, should be bundled with a small set of CA certificates, the root CA certificate set, that would ensure that any certificates with a path back to one of those certificates could be validated by that application.
The CA certificates to bundle were chosen by the vendors, companies such as Netscape and Microsoft, of the packaged application. Some vendors might have a program that was simply payment in exchange for inclusion, others might require some auditing or vetting be done of the CA's procedures. An illuminating discussion of these procedures can be seen in the three years of comments on a bug filed to request the CAcert root cert inclusion into the Mozilla browser - in the interim its underlying platform (NSS) has stopped bundling any Root Certificates.
Three other closely related assumptions are:
- The implementation of cryptography, SSL and client-side PKI moves from the application into the underlying platform: Windows, Java, NSS/NSPR.
- SSL, as deployed on the Internet, tended not to require client certificates, and so the path validation was reduced to the client (e.g., the a web browser through its underlying platform) validating a chain of certificates provided by the web server. This chain would only need to consist of the certificate for the web server as a subject, and potentially any certificates of intermediate CAs between that issuer and a root CA shared between the client software and the web server.
- The web browsers would not make any policy decisions based on the certificate. If a path could be validated, the browser would display a lock icon or color the title bar, but what to send in a HTTP GET or POST in a form or file upload to the web server was entirely at the discretion of the end user.
Of course, PKI with root CAs as used by SSL for Internet e-commerce sites has become successful; VeriSign for one claims that they "currently secures over 450,000 Web sites with digital certificates - including sites for 93% of the Fortune 500."
And organizations which wish to issue their own certificates for use by users within their organization can do so, without being connected to one of the commercial Internet CAs, by having each user in the organization manually add the organization's certificate to their computing platform's root certificate sets.
Currently, manually removing certificates from the platform's root certificate set is also possible, although that will become less of an option as the platforms themselves start to rely on PKI for its own management, such as code signing. Java, which (in version 1.4.2) comes with 15 bundled CA certificates in java.home/lib/security/cacerts, permits them to be removed using the Key and Certificate Management tool. Windows, which comes with 100+ bundled CA certificates, also describes How to remove a Root Certificate from the Trusted Root Store, but also lists Trusted root certificates that are required by Windows Server 2003, by Windows XP, and by Windows 2000:
The follow certificates are necessary and trusted root certificates in Microsoft Windows 2000 and later operating systems:
Issued to Issued by Serial number Expiration date Intended purposes Friendly name Status Copyright (c) 1997 Microsoft Corp. Copyright (c) 1997 Microsoft Corp. 01 12/30/1999 Time Stamping Microsoft Timestamp Root R Microsoft Authenticode(tm) Root Authority Microsoft Authenticode(tm) Root Authority 01 12/31/1999 Secure Email, Code Signing Microsoft Authenticode(tm)Root R Microsoft Root Authority Microsoft Root Authority 00c1008b3c3c8811d13ef663ecdf40 12/31/2020 -All- Microsoft Root Authority R NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc. NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc. 4a19d2388c82591ca55d735f155ddca3 1/7/2004 Time Stamping VeriSign Time Stamping CA R VeriSign Commercial Software Publishers CA VeriSign Commercial Software Publishers CA 03c78f37db9228df3cbb1aad82fa6710 1/7/2004 Secure Email, Code Signing VeriSign Commercial Software Publishers CA R Thawte Timestamping CA Thawte Timestamping CA 00 12/31/2020 Time Stamping Thawte Timestamping CA R The follow certificate is also a necessary and trusted root certificate in Microsoft Windows XP and later operating systems:
Issued to Issued by Serial number Expiration date Intended purposes Friendly name Status Microsoft Root Certificate Authority Microsoft Root Certificate Authority 79ad16a14aa0a5ad4c7358f407132e65 5/9/2021 -All- Microsoft Root Certificate Authority R
(Yes, expired certificates must be kept.)
Subsequent posts will look at the relationship between policy and PKI.