Managing Digital Keys

Entrust/WebCA supports a single level of administration, though multiple administrator accounts can be created. After the user places a certificate request, an administrator picks it up from the main queue and may assign it to his own private queue. Entrust/WebCA, like Xcert, keeps signed audit logs that eliminate the ability to tamper with these files without detection.

Entrust/WebCA does not directly use client certificates for administrative authentication; instead it uses a standard password over an SSL connection to the Web server. However, it does enforce more stringent restrictions on administrator password length and construction than the other products.

In our testing, the administrative interface was plagued by a couple of bothersome bugs. For example, when we clicked the "back" browser button while reviewing the main request queue, all the certificates incorrectly moved into the private queue. In addition, we were frequently asked to reauthenticate unexpectedly. We also encountered a few annoying but minor problems during installation. For example, administrative URLs placed in the NT start menu are not changed to use "https:" following the switch to SSL, though this switch is part of the normal installation process.

Entrust/WebCA uses the Netscape X.509 certificate extensions that define locations for CRL checking, renewal forms and policy statements (as defined for Netscape Navigator 3). These may be found at home.netscape.com/eng/security/cert-exts.html. Entrust/WebCA doesn't come preinstalled with the expected PKI X.509 extensions. Like Sentry CA and Certificate Server, Entrust/WebCA uses its own custom LDAP schema extensions.

Standards May Save PKI
Public key infrastructures have a long history, dating back at least as far as Privacy Enhanced Mail (PEM) and its X.509 version 1 PKI, which assumed a stric t hierarchy and limited the CA to supplying certificates for its own section of a directory tree. The IETF's PKIX working group ha s been striving since 1995 to develop standards needed to support interoperable X.509 infrastructures. Their most important work, now in its sixth draft, is just being unveiled.

PKIX specifies standardized X.509 extensions, to which none of these CA products adheres without customization. It defines data attributes for items like key usage (for example, S/MIME, SSL client, SSL server or CA), CRL distribution points, a certificate policy statement location and so forth. As the PKIX standards mature, the new certificate and CRL attributes will certainly be adopted by all of the products reviewed here.

If you accept the current limitations of "open" PKI, any of these products can do the job of serving up X.509 certificates. Your choice will depend on your ability to write custom applications in HTML/JavaScript or a server-side scripting language, and the depth of your understanding of public key cryptography and data structures.

David Willis can be reached at dwillis@nwc.com.
Greg Shipley is a consultant for the Chicago branch of Ciber Network Services. He can be reached at gshipley@chi.ciber.com.

Making a List and Checking it Twice
The problems with PKI fall into two main areas: client-side support and the intelligent infrastructure. Before open PKI can be truly viable, standards and features that just aren't there today must exist in commercial products. Many of these items are addressed by the IETF PKIX standards, and others are simply product implementation issues.

Client Support
· Clients need to use diverse but well-defined methods to place a certificate request. At minimum, requests should be permissible through e-mail, FTP, HTTP and by a trusted third party.

· Personal certificates and private key material should be stored in a common format that may be shared across multiple applications, with optional access control lists (ACLs) to restrict the use of some cryptographic material.

· Storage of key material should be kept on secure media like well-protected disks, tokens or smartcards.

· Clients must have multiple methods of receiving their personal certificate, such as e-mail, HTTP or via disk file. Only one method per protocol should be adopted.

· Clients should provide automatic certificate validity checking using two distinct methods: CRL downloads in the background, for offline use; immediate online verification, using a method such as OCSP.

· When a certificate is deemed invalid, either through CRLs or online checking, the certificate store should be updated without intervention by the user.

· Faster methods of certificate chain traversal are needed. Some implementations require the entire certificate chain to be verified, using many expensive signature verification operations. Others don't walk the entire chain and compro mise security. Once again, OCSP solves t he problem by offloading processing to the security server.

· Users should not assume that a commercial PKI service such as VeriSign can be used exclusively, or even by default. Users incorrectly assume that commercial services are the only way to go.

· Clients should be centrally manageable. Default configurations such as approved directory servers and certificate signers, certificate usage and approved software publishers should be locked down in some environments.

· Password policies to protect the certificate store should be enforceable.

The Intelligent Infrastructure
· Knowledge of the relationships among CAs should exist within the network, not within each client.

· Within a closed user group, such as an intranet, private keys used for encryption can be held in a central repository. This keeps ownership of corporate assets within the corporation and protects against data loss.

· When there's centralized escrow of encrypti on keys, a second signing key should be issued that is held exclusively by the user. This keeps users' identities private and aids nonrepudiation.

· Consistent data structures, in the form of well-defined X.509 extensions and LDAP object classes, should be used. The IETF PKIX standards address these issues.

· The security infrastructure must be well-integrated to the directory. New requests for certificates should be matched against certificates held in the directory to prevent the accidental obsolescence of valid public keys.

· Servers should support multiple administrative levels, both within a server and across a distributed network. Policy-level administrators should assign responsibility for a partition of the network to other administrators.

How We Tested
Our original test plan sought to determine how multiple CAs (certificate authorities) would handle client interaction, CRL (Certificate Revocation List) distribution, c ross certification, directory integration and validity checking. We wanted to see a deployed PKI (public key infrastructure) based on commercial software--a system of both servers and clients--not something that would require months of development work by security experts. We expected to encounter a system that could utilize distributed directories, with clients grabbing recipient certificates and encrypting messages transparently. Most of all, we expected to find CAs that would create an intelligent, distributed security network and shield the details of the underlying infrastructure from clients. Soon after getting our hands dirty, it became obvious that even though this technology has come a long way since our last look, it still has quite a journey ahead of it (see www.NetworkComputing. com/806/806f1.html).

For this test, we installed the servers in Network Computing's lab in San Mateo, Calif., and a site in Chicago, using the Internet for communications between sites. We examined all servers from eac h site using Netscape Communications Corp.'s Communicator 4.03 for Windows95/NT, as well Microsoft Corp.'s Internet Explorer 4.0 and the Outlook Express S/MIME (Secure Multipurpose Internet Mail Extensions) client. In actual practice, certificate servers are not heavily burdened, so performance testing was not relevant.

After establishing the directory tree using each product's native LDAP (Lightweight Directory Access Protocol) directory, we installed self-signed certificates to the root CA and Web server. Then we requested client certificates for SSL (Secure Sockets Layer) and S/MIME from each browser. We sent S/MIME mail between users, starting with certificates issued by a single vendor's product, then testing certificate compatibility by sending mail between different manufacturers' servers. We also established SSL connections between clients and servers.

We examined the CRL of each product, attempting to download the list to both Internet Explorer and Communicator. Finally, we conducted LDAP lo okups to attempt to download other users' certificates for S/MIME. If it was available, we used the HTTP interface to download other users' certificates.