 |
 |
| C O L U M N | |
| |
PKI at a Crossroads May 1, 2000 By ROBERT MOSKOWITZ 
You'd think that all the years of toying with digital certificates would have
yielded the tools to build effective PKIs (public key infrastructures). The
standards community has been working on supporting protocols for at least four
years. Unfortunately, though, consumers have not pressed vendors to develop
interoperable technology, and now it seems that building a PKI is harder than
we'd thought.There are plans a PKI builder can follow (see attached Internet draft.) These plans identify three building blocks: RAs (registry authorities), CAs (certificate authorities) and repositories. Even if we were to buy the RA stapled to the CA, the CA-to-CA method is surprisingly daunting to the few brave builders attempting to glue together CAs. X.509v3 defined two methods for joining CAs: hierarchical signing and cross-certification. The liability aspect of cross-certification, along with many of the non-interoperable methods for cross-certification, have many CA vendors dodging the issue with "trusted lists." Trusted lists, as vjj implemented in most Web browsers and many e-mail packages, are easy for the developer. Unfortunately, these implementations present a "trust leakage": The client defines the community of trust, usually erroneously, instead of the community in which the client has membership. So hierarchical signing and cross-certification still offer the best method for controlling trust. Hierarchical PKIs have been implemented rarely, and only in very narrowly defined administrative domains. Even the U.S. government moved from its hierarchical plans to a structured cross-certification PKI model in 1998. The user community desires cross-certification, so you'd think vendors would have been hard at work getting it into products, but recent events in the U.S. and U.K. governments and NACHA (National Automated Clearing House Association) have shown differently. It's not that vendors have been totally ignoring the mechanisms to accomplish CA cross-certification. Many vendors, including Entrust and Baltimore Technologies, have implemented solutions for their enterprise products, and the IETF has included CA cross-certification in the Certificate Management Protocol (RFC 2510). However, there hasn't been any demonstration of interoperability of ccr (cross-certificate request) and ccp (cross-certificate response) from RFC 2510. So how have organizations performed cross-certification for the handful of multivendor demos and pilots? The team at NIST that set up the pilot Federal Bridge CA spent a reported two weeks handcrafting certificate requests using PKCS #10 formats to cross-certify an Entrust and GTE CyberTrust CA. The NIST team is experienced with PKI products and even its members had difficulty using the old methods (PKCS #10 and #7) to cross-certify two CAs. Other user groups gave similar reports at the PKI Open Forum's first meeting (see www. pkiforum.org.) CA cross-certification poses a real barrier to creating the powerful PKIs that have long been promised. But, thankfully, it seems that most groups will perform CA cross-certification in the foreseeable future. Many of the vendors at the meeting felt the problem would correct itself by the end of the year. There were others present who realized that projects will not stand still for a year or more, so vendors and consultants will undoubtedly be handcrafting CA cross-certifications until certificate certification really works. It's all so frustrating. One of the design goals in X.509v3 was to add CA cross-certification. Although this is in the specs, it is so difficult to build a PKI using CA cross-certification that some groups have at least delayed or pulled back designs built around it. Until that day when the barrier to CA cross-certification is getting cooperation from the lawyers, instead of the technology, we need basic tools from our CA vendors. Robert Moskowitz is a senior technical director at ICSA. Send your comments on this column to him at rgm@htt-consult.com.
| |
