Network Computingwww.networkcomputing.com

Entrust Technologies Entrust/PKI 5.0
Entrust/PKI 5.0 offers many of the features an enterprise needs to get a PKI up and running. With the ability to customize just about every aspect of the CA and certificates, Entrust/PKI can meet virtually any organization's needs. Entrust/PKI comes into its own with a suite of desktop products, but it doesn't really need them. Tiered, role-based and bulk management, great searching tools and simple architecture all speak to Entrust Technologies' experience in serving the enterprise market. However, not all is rosy with Entrust/PKI. We couldn't build the exact PKI structure we wanted, because foreign PKIs could be joined only at the root CA and we wanted to join sub-CAs. Still, this is a minor complaint, and everything else about this package was strong enough to earn it our Editor's Choice award.

Entrust/PKI's architecture is rather simple. It ships with an Informix database that stores the CA's internal data. A PeerLogic directory that is used for publishing data to the world is sold separately. The package also includes one CA and an RA, which communicates with the CA. Other components include Web Connector, which is used to register Web users, and VPN Connector for VPN users. During the installation process, five users are created to manage Entrust/PKI. These users include three master users, who have complete control over the CA; a directory administrator; and a first officer, who configures the PKI and adds users.

Entrust/PKI creates entries for users and other end entities, such as Web servers, when they are created in the RA. The certificate parameters are created, and a reference number and an authorization code are created to match the certificate. When a user retrieves the certificate, he or she simply enters the reference number and authorization code. At that point, the client application generates keys locally and completes the certificate request with the CA. This gives the administrators complete control over the content of the certificates and facilitates bulk loading of users.

Who You Gonna Trust?

We created a hierarchical PKI, in which each CA had its own directory within the Entrust/PKI framework. In the process, we spent more time chaining the PeerLogic i500 directories than on signing the certificates. The directories need to be chained so they can publish and retrieve data such as CRLs (certificate revocation lists) automatically. Next, we went to our Entrust/PKI root CA and defined the subordinate CA and noted the reference number. During the installation process, we were prompted for the authorization number, and the CA retrieved its certificate signed by the root CA.

Although Entrust/PKI can simultaneously support both peer-to-peer and hierarchical PKI, also known as hybrid PKI, a hierarchical PKI can be joined only at the root CA, because letting subordinate CAs create their own relationships violates the sanctity of a trust model and may lead to very complex trust relationships (see "Joining Hierarchical PKIs With Entrust" at right).

Subordinate CAs can short-circuit policies that should be enforced at the root CA. Ideally, the PKIs should be sparsely connected, and the end applications should use policy mappings and certificate attributes, such as extended key usage, in determining whether to extend trust to a specific certificate.

Without smart applications, all certificates signed by the foreign CA will be trusted by users on the local CA. While joining PKIs is not prevalent today, it can be a problem in situations where departmental users need to trust a foreign department's certificate without trusting the entire foreign organization's certificates. Both Sentry and UniCERT can join sub-CAs at any point in the PKI.

Access control within the CA is important because key functions and roles need to be divided among trusted administrators; leaving one person with absolute power is very risky. Entrust/PKI has a flexible and foolproof role system that simply beats anything in Sentry or UniCERT. Upon installation, Entrust/PKI has five predefined roles, which will meet most needs. Auditors, for example, can view logs and certificates but can't change the PKI; directory administrators can perform functions in the directory but can't add or remove users. The ability to define roles provides granular access control to the key functions.

We also built custom roles, such as one that let us reassign enrollment reference codes and authorization numbers. This was a simple matter of creating the role and assigning the appropriate rights. Building roles can be complex because of the dependencies between parts of the PKI and directory. Fortunately, Entrust checks dependencies before creating the role. For example, we had to assign a number of viewing rights to the role so that user information would be available. Users also can exist in multiple roles simultaneously.

Adding Users

Before adding users, we wanted to modify the data that would be held in the certificates. In our case, several fields were added to hold the users' locations and job titles. We also could have added the fields to the database and not to the certificate, which minimized information leakage. Remember, all data in the certificate is public. To change the template, which also changes the fields in the GUI, we edited the certificate definition file. This file contains definitions for user-certificate types, such as enterprise user or Web user, and for certificate extensions. We created a new certificate type so we could still use Entrust/PKI's default certificate types. The certificate definition file is well-documented, and adding the certificate extensions was not difficult. We did run into one issue having to do with new entries: We had to ensure there were no extra spaces at the end of the line. Once the certificate definition file is created, Entrust/PKI checks the file syntax and won't import the file if there are any errors.

Bulk loading of users is straightforward. Entrust/PKI uses TCL (Tool Command Language) script to automate the retrieval of user information and pass commands to the bulk-load process. Through scripting, we could add, remove and modify users in bulk--handy tasks when dealing with a large number of users. Keep in mind we're not talking about a simple user loading. To prepare our own bulk load, we created a list of 500,000 user names and merged that data with the certificate data we wanted, using an application we wrote on the spot. This worked well in our test environment, but organizations with existing user information will need time to construct script files and interface with existing databases.

After we created our data file, we logged into Entrust/PKI's RA and entered the "bulk operations" part of the GUI. We selected our data file, and the log file was completed automatically. When we kicked off the script, two to three users were added per second. Entrust/PKI did not create the user key pairs or the certificates: It creates only the users and generates the authorization codes and reference numbers that are used to create a certificate. We did run into a minor problem with the bulk load: The PeerLogic directory halted mysteriously. After talking with technical support, we added more processes, and the script ran to completion without a problem.

Miscellaneous management features, such as searching for users or auditing the logs, are both flexible and straightforward, letting us get to the information we needed. We could search for users in either the directory or the CA using a number of search criteria. Additionally, users could be added to groups within the PKI and could be enumerated through that mechanism as well. All the information pertaining to users and their certificates is presented for administrative review. Auditing the logs is equally simple, with search fields to pare down the logs to a manageable level.

Entrust/PKI 5.0, Entrust Technologies, (972) 671-9542, (888) 690-2424; fax (972) 943-7305, www.entrust.com.