Ultimately, we'll be looking to the IETF's PKIX (Public Key Infrastructure X.509) standard and OCSP (Online Certificate Status Protocol) for a real solution. Patrick Richard, Xcert's vice president of technology and strategic planning, helped write the IETF draft for OCSP. Representatives from Entrust Technologies, Netscape, SPYRUS and VeriSign also participated. Xcert was first to deploy it. OCSP answers one of the biggest challenges facing the deployment of PKI: how to hand le compromised or revoked certificates efficiently.

You might expect CRLs to be downloaded periodically, or that you might be offered a single-button option for comparing the CRL to the client's store and revoking bad certificates. You would be wrong on both counts. The only way you can use CRLs is by laboriously matching up two lists (that is, the list in your local store and the one in the CRL) and deleting certificates by hand. Since this, of course, is so impractical, certificates used by commercial products remain valid until they expire (see screenshot at left).

OCSP moves away from this static-list model toward a dynamic one. It defines LDAP and HTTP status queries designed to provide fast response time and high availability. In response to a client query, the OCSP server sends a simple status message (valid, invalid, revoked, not revoked or expired). Using this model, the load is balanced between the client and the server and it becomes possible to do real-time certificate checking on a per- transaction basis. XUDA (Xcert Universal Database) API offers this functionality, and CA/Web server system utilizes it--if the client is intelligent enough to use it (see diagram at right).

Until we see more intelligence in the certificate infrastructure itself, concepts such as cross-certification--the ability of one certificate authority hierarchy to "trust" another--remain concepts and nothing more. We initially hoped to test this capability, but the lack of intelligence in the PKI and the client made cross-certification useless without extensive development. Here, Xcert Sentry CA provides the most promise, both in programming interfaces and adoption of standards.

Xcert Software Sentry CA 1.41
Sentry CA ships in eight flavors of Unix as well as Windows NT for Intel, offering administrators a range of platforms. Sentry CA doesn't have a glossy front-end interface, but what it la cks in polish it makes up for in power. It's what Xcert has put under the hood that propels this CA past the competition. Sentry CA consists of three primary components: a front-end SSL-enabled Web server, an issuing CA process and a back-end LDAP-compliant X.500-based directory. In other scenarios, a seemingly proprietary package may be a mark against such a product, but in Sentry CA's case the packaged solution is one of several saving graces. Sentry CA helps administrators avoid the headache of configuring all the various components to communicate with each other--something we had trouble with when using the other products.

Sentry CA's administrators interact with the server through a series of HTML forms. Although bland, the entire Sentry CA interface (both client and administrative side) are basic HTML pages that can easily be augmented or completely redone. Once installed, two NT services are activated: the Web/CA server and the back-end XUDA database server. Certificate request forms are handled s ecurely on Port 444, and the administrative services are handled on 443. Unlike the other products, two organizations are created within the initial database--one for general use and the other for administrative use. Once functional, administrative duties can be distributed among several people. Using issued "administrative" certificates, security officers can grant and revoke certificate requests from the general certificate queue.

Xcert eases the installation and administrative burden with its integrated Web server and directory. Entrust's Web/CA, for example, doesn't include a Web server, which limits the CA administrator's authentication method. If, for example, using Web/CA you choose IIS version 3 as your Web platform, all administrative authentication must be done through passwords. This is because IIS version 3 checks only a client certificate's validity, not the actual identity of the client. In contrast, Xcert and Netscape rely on X.509 certificates, which are processed by the Web server.