
Web browsers are their own repositories, carrying the root and signing certificates they trust. Rarely is there any concern about one of these certificates expiring, since there will be a browser update with a new certificate file. This model has a number of shortcomings; it has no support for CRLs (certificate revocation lists) and provides no way to acquire a user certificate based on the user name. These two issues alone argue for the abandonment of the browser certificate file--to be replaced by a certificate cache--and the move to some real, active repository.
There are two approaches to supplying a certificate repository. All of the certificates can be in one, large distributed database, or each signing certificate can maintain its own repository and have a means of querying the other repositories for information for its users. Although the large distributed database is intimidating to consider, one is actually already deployed: the DNS. There are DNS resource records defined to support its use as such a repository. It would be very easy to use DNS, provided that DNSSEC (DNS security) were fully deployed so systems could trust the certificate records in the DNS. However, DNS cache files for the Internet's root servers are already too large for even the largest Unix systems.
A large, replicated LDAP server is yet another approach. It would be a new service, so it could be deployed with spoofing-attack-prevention. This is as important a requirement as high reliability. Registered certificate signing agencies would post all of their certificates into this server mesh. The problem here might be one of scaling. Even for a closed (large) business community, the LDAP server would have to support potentially millions of certificates. This leads to the consideration of a grouping of LDAP servers, joined by DAP (Directory Access Protocol).
On the surface, the LDAP/DAP approach has the needed pieces for our certificate repository access protocol. It provides a lightweight protocol between the users of the certificates and the repositories, and a full-feature protocol for queries between repositories. It is a very good choice for a hierarchical PKI and the browsers that are positioning themselves to work in such an environment. DAP, however, has search bounding problems. These will not show up in a multiple-repository hierarchical PKI, but will likely impact queries in a multiple-repository cross-certified PKI.
Building the Infrastructure A number of business communities and governments are starting the process of creating their CAs. They are linking them by signing or cross-certifying and publishing all of their information in business-class repositories. To be successful, it is important to grasp the fundamental differences between the certificate types and the various roles played by certificate signing systems and certificate publishing systems. Getting the certificate publishing system right will determine the success of the digital certificate deployment. Get this down pat before you get to the more interesting authorization and authority-delegation certificates and the business-enabling power they bring to digital certificates.
Robert Moskowitz is a senior technical director at the International Computer Security Association and a member of the Internet Architecture Board. He can be reached at rgm@htt-consult.com.
|