Nonetheless, PKIs do promise better authentication, simplified encryption and digital signatures, elimination of clear-text passwords on the wire and, ultimately, single sign-on across multiple applications and services. Used appropriately, attributes in the certificate capture extended information on an individual or other entity. For now, however, none of the current crop of commercial products can accomplish any of these features without extensive programming.

All Revved Up, Nowhere To Go
At this point, the only widely adopted "productized" applications using X.509 certificates are Internet-related--Web browsers and NNTP (Network News Transfer Protocol) readers that support SSL, POP/IMAP mailers that support S/MIME, and LDAP (Lightweight Directory Access Protocol) clients. The drawback is that each product maintains its own certificate repository. Even Internet applications suites like Netscape Communicator and Microsoft Corp.'s Internet Explorer 4 (IE4), which share certificate stores across components within their own suites, still lack critical security services (see "Making a List, Checking It Twice," page 66).

The certificate servers reviewed here are simple, but managing certificates isn't. For example, the certificate servers r eviewed here can take requests for new certificates, queue them for administrator review and issue the certificates for client retrieval. They support custom extensions of the X.509 version 3 certificate and use a Web server for administrative and client functions. Using the Web server interface lets the administrator easily customize what users see when they contact the certificate server. When other users need a public key, they can contact the certificate server via HTTP. An alternative approach to finding another user's key uses an LDAP-enabled directory to facilitate certificate lookup.

None of the servers we evaluated provides real separation of administrative duties within a single server, though Xcert comes close. None draws a clear line between the duties of the system and network administrator as well as the security and policy administrator. Netscape and Xcert create some separation by using a hierarchy of CAs, delegating authority for certain parts of the directory from the root. Surprisingly, Entrust/WebCA doesn't support this at all; it cannot subordinate one certificate authority to another, and all administrators assume an equal level of control.

All of the products can deliver certificates to the requesting user via the Web. Yet due to differences in the way Communicator and IE4 generate public keys and request and receive certificates, the administrator must work with different server-side interfaces for the two browsers. Once a certificate is received at the client, it is typically protected by a password--though this is not universally true, either. Fortunately, once you overcome the hurdle of getting a certificate into your favorite client, you'll be able to exchange S/MIME e-mail without any problem, as we found in our tests.

Although these products share common methods of requesting, processing and approving certificates, Entrus t/WebCA also offers an impressive "Generated-Secret" function. When administrators preload requests on behalf of a user--one at a time or in bulk--autho rization codes are generated that the client uses to download the certificate via HTML. During this download stage, the private key is generated. This approach requires fewer steps for a user to get a certificate, and also is the method used by the standard Entrust security product.

In general, once an S/MIME client retrieves and stores a user's certificate, it is able to sign outgoing messages. Encryption to other users, however, requires that the recipient's certificate be retrieved. The logical way of doing this is via an LDAP directory. Although efficient once configured, this method introduces several problems. First, LDAP servers need to be defined within the browser. Some newer technologies, such as Netscape's AutoAdmin combined with Mission Control, can push LDAP server locations to the clients.

Current LDAP installations have other constraints. Suppose you need to send an encrypted message to someone outside the organization, perhaps on the Internet. Well, you can't. There is no set way to d iscover an organization's LDAP server. Something equivalent to DNS' MX (Mail Exchange entry) would come in handy here, or at least some commonly adopted LDAP server naming practices.

For users who wish to get other people's certificates from a Web server, only Xcert and Netscape will suffice. Entrust/WebCA cannot perform this task. The only way to get S/MIME keys with Entrust/WebCA is by receiving signed e-mail from the owners.