Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Managing PKI trust anchors (20070726)
Many modern operating systems, web browsers, virtual machine, embedded Internet devices, smartcards etc. have a local file or database containing a collection of one or more public keys, and rely upon these public keys to be able to build X.509 certificate paths. A typical web browser contains the public keys of several dozen well-known certificate authorities (CAs), storing these keys as self-signed certificates, referred to as "root certificates" or "trust anchors".
For a Certificate Authority, having their public key in a client's trust anchor collection means that the client will be able to build a trust path to any servers who certificates are issued by that CA (or an intermediate CA whose certificate is issued by that CA). Organizations that wish to issue their own certificates for their intranet servers, without being connected to one of the commercial Internet CAs, must have each user in the organization manually add the organization's certificate to their computing platform's root certificate sets.
The client root certificate file was not a built-in requirement of public key cryptography or X.509. Originally, X.509 assumed that building a certificate from a client A to a server 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, should be bundled with a small set of CA public keys as 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. Java version 1.4.2 came with 15 bundled CA certificates in java.home/lib/security/cacerts; Windows 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. 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.)
Scheduled for Friday (20070727) is an IETF BOF on "Trust Anchor Management" (the BOF's PowerPoint welcome and problem summary slides have already been posted). The group proposing the BOF has had a mailing list since June 2007, and drafted a strawman charter and problem statement.
The second draft of the "Trust Anchor Management Problem Statement" (draft-wallace-ta-mgmt-problem-statement-01 of July 2007) by R. Reddy of NSA and C. Wallace of Cygnacom discusses some of the problems, including
- A computer system may have multiple distinct trust anchor stores (root certificate files); each of which is locked into an application or operating system differently and needs its own proprietiary tool to manage. There is no standard way to report on the content of a trust anchor store
- There is no standard means to limit the scope of applicability of a trust anchor that is just a public key: that it can be used for one purpose or application but not another.
- Trust anchors as public keys in self-signed certificates provide
no useful means for establishing trust in the information contained in the certificate
.