Network Computingwww.networkcomputing.com

PKI, large or small, is still waiting for the "big event," the easy-to-install and -use version, in much the same position as LANs in the mid-'80s. PKI is so complex, lacking in established, concise standards, and tied up in legal FUD, it's no wonder it's not widely deployed. As noted in RFC 1925, with sufficient thrust, pigs can fly; it's just not necessarily a good idea--you don't know where they're going to land, and you don't want to be sitting under one that's airborne (see RFC 1925 Truth No. 3 at ftp://ftp.isi.edu/in-notes/ rfc1925.txt). PKI is the Internet pig looking for thrust. Only a handful of companies and organizations--including the Department of Defense and Caterpillar--are now using PKI. And that's not likely to change until 2001 or so.

Today, a global PKI is beyond comprehension--there are too many ifs that would need to happen, such as cross-certificate or signing of all certificate authorities; global repository for at least CA certificates, CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists); certificate path construction logic that works; and common certificate management protocols. The absence of any of these will derail creation of a global PKI. Additionally, cross-jurisdictional (i.e., international) liability concerns will continue to chill all discussions.

The PKIs of 1999 are following the credit-card model. Each PKI serves some limited business purpose. Therefore, a person, company or server must plan to be part of more than one PKI, which means managing multiple certificates in some sort of digital wallet. As in the case of credit cards, where the user has to read the icons on the cash register to get the right card, something has to clue in the user regarding the correct certificate to use for a transaction. There is no "best current practice" for this function, though extended KeyUsage is frequently proposed. Each of these certificates costs money and time to acquire and maintain. Each issuer does its own I&A (identify and assure) process for the applicant and charges accordingly. (Note that VeriSign's $10 user certificate has no I&A component.) Many technologists, lawyers and politicians see this as the natural way; just as we all carry physical key rings, so too will we carry PKCS 12 "wallets" of certificates.

Perhaps the most glaring deficiency in today's PKIs is in certificate management. For too many years the focus on PKIs centered on agreements about the content of certificates and the trust relationships between CAs. Managing those certificates seemed to be a magic box on the flow diagrams (you know the cartoon; "magic happens here"). The lack of attention to managing certificates in the early years has led to the development of two forces: use of RSA's PKCS 10 and 7 formats in a cut-and-paste with Web or e-mail interfaces, and proprietary enrollment protocols like those used in Entrust. Although some 100,000 servers have used the RSA method to get SSL certificates, and more than 2 million users have VeriSign DigitalIDs, the PKCS 10/7 cut-and-paste method will not serve us much longer, as it is not very user-friendly. A real transactional management protocol is needed. The two contenders for the title are CMP (Certificate Management Protocol) and CMC (Certificate Management Messages over CMS), both of which are just emerging from the standards development process.

This lack of a standard certificate management methodology is perhaps the greatest barrier to PKI deployment. With each CA product using its own methodology, or a totally

inadequate methodology, applications have become serfs to the CA king. To a large extent this has resulted in a free-for-all among the most popular CA products to lure application support. The CAs have "PKI-enabling" programs, for which they sign on as many applications as possible to use the CA's toolkit for interoperability. The popular applications thus integrate as many as possible, inflating their development costs and adding to user administration workload.

As we head into 2000, the state of PKI is disarray. Large communities of interest, including automotive, banking, medical, educational, government and insurance users, are frustrated in their inability to set guidelines for their members. They are also unable to develop solid time frames for their COI (communities of interest) PKIs. In this confusion, some of the large PKI players are playing hardball. "Use our product or be doomed to failure and loss of business advantage," they say--looking at some CA vendors' Web sites for the partner programs can be quite enlightening. The small consumers are forced either to stay away from PKI, or select a software bully and hope that it wins the PKI wars or at least a large interoperative share.

--Robert Moskowitz