Network Computingwww.networkcomputing.com

Print this Page E-mail this URL

Of course, embedding PKI functionality into the OS simplifies integration, management and usability issues. Given a common interface, developers can leverage existing services in the OS. By the same token, certificate management and usability will become simplified because certificates can be more easily shared among applications, resulting in fewer certificates. However, without support for common standards, such as PKCS #11 (Cryptographic Token Interface Standard), applications and developers will have to support multiple standards.

Basic functions, such as sharing certificate stores, are not possible across applications. The reason is simple: Only with the recent rollout of RSA's PKCS #15 did a standard way to share software-based tokens between applications come about. Today, it is still common to have a Web-manageable product that requires a specific browser, so managers may need two browsers and two key stores. If other PKI-enabled applications move onto the desktop, additional certificates stores may be required. While this isn't much of a problem with limited rollouts found in pilot projects, the management problem will grow out of control with general distribution.

Token cards containing the secure certificate storage and cryptographic engines provide some relief from the certificate-sharing problem, but they are expensive (prices range from $44 per I-key from Rainbow Technologies to the $795 Chrysalis-ITS FIPS-140 L2-certified Luna 2), and applications require direct support for each vendors' cards. PKCS #11 specifies an API for accessing tokens, but the implementation is vendor-dependent and requires vendor support. PKCS #15 abstracts the hardware issues from the certificate-access issues by letting vendors use a common set of APIs. The certificates can be stored on a virtual device on the file system or on a token. Any application that is PCKS #15-aware will be able to access the certificate store. But PKCS #15 is a new RSA standard, and if Microsoft doesn't support it in Windows 2000, it will likely fall by the wayside--at least on the Windows platform.

Later this year, Netscape is expected to announce Netscape Personal Security Manager, an application that automates much of the end-user PKI management and can be seamlessly installed into the Communicator suite. Certificate creation, signing and selection will occur with little user intervention within the Netscape application suites.

Where Do You Keep Your Attributes?
Certificates provide more than identification to applications and users. Certificates also carry information--called attributes in PKI parlance-- about the certificates themselves, such as a certificate's purpose and information about the presenter.

Attributes are used by application processing ranging from identification to access control to environment configuration. An online store could issue an attribute certificate detailing customer information and tie it to the user's digital ID issued by a separate CA. However, the more attributes that are inserted into a digital certificate, the shorter the effective lifetime of the certificate. As attributes change, the certificate must be revoked and reissued. A rule of thumb for the certificate lifetime is to divide a certificate lifetime by the number of attributes it contains. The solution is to remove attributes from the digital ID--which attributes you move will depend on your needs.

How the attribute information is stored depends on the vendor and presents some implementation issues. One strategy, adopted by Xcert, stores attribute information in the directory and creates attribute certificates as needed. Any changes to a user's attributes are immediately reflected in the directory and the attribute certificate. The signing of the certificates will add to server load, so commonly used certificates can be created for faster retrieval. Adding attributes requires administrators to write access to the directory, along with rules to limit user access to specific entries.

Attribute certificates, which are being adopted by vendors such as Baltimore Technologies, provide another way to store attribute data. Attribute certificates can be stored centrally with the digital ID or distributed in attribute directories. For example, a human resources department might issue a digital ID to a new employee. When the employee gets to his or her department, network administrators issue an attribute certificate detailing the employee's access rights and other departmental information. All that needs be done is to relate the attribute certificate with the user's public certificate issued from HR. Each department manages the attributes that are important to its specific functions.

Long-lived attribute certificates carry the same burden of management when attributes change and certificates need to be revoked, because changing a field in a signed certificate invalidates it. The simple answer is to make attribute certificates short-lived and reissue them often. How short-lived depends on what the attribute certificate is used for and balances the likelihood the certificate will be revoked prior to expiration (increasing the amount of revocation data that is generated and maintained) against the cost of certificate renewal. For example, an attribute certificate used to grant access to specify spending authorizations should be renewed frequently to reflect any changes, while an attribute certificate containing personnel data may need to be renewed only semiannually. The point is to keep revocation data to a minimum while still reflecting changes in a timely manner.

Managing Risk
If PKI is ever going to be widely used for building extranets, it needs to model and support existing business relationships. Today's PKI landscape shows few pilots within organizations and even fewer that span organizations. To enable business-to-business e-commerce, PKI must incorporate the same types of legal contracts that bind value chains in the brick-and-mortar world. These contracts specify roles, responsibilities, warranties and recourse. PKI must provide these same assurances to take off.

The technology is the easy part when it comes to PKI. Creating a universal PKI that will reduce risk and operational costs is very complex. Machines trust each other implicitly; humans do not. How do you, as a network administrator, know that a trading partner is running its CA according to its certificate policies and certificate practice statements? How can you be sure that your trading partner's root CA can be trusted? If there are problems and the PKI is not being managed responsibly, what recourse do you have? How can you be sure a trading partner can cover expenses incurred during business? These are questions PKI can't solve.

But there is some hope. Organizations such as Identrus promise to bring four-corner trust models established within financial institutions to PKI-enabled applications. More than a PKI, Identrus brings risk management, process controls, legal authority and financial backing to the international community. Member institutions must enforce a minimum set of operational guidelines for CA and are subject to auditing by Identrus, which gathers financial information and sets acceptable levels of spending for members. Other vendors have established PKI organizations aimed at bringing diverse groups together under one CA, such as Entrust and VeriSign, but they lack the risk management and the existing relationships enjoyed by the financial institutions. Identifying which model ultimately will prevail is anyone's guess, but one thing is certain: A seamless worldwide PKI isn't just around the corner.

Send your comments on this article to Mike Fratto at mfratto@nwc.com.