XKMS and PKI

PKI is complex because the issues it deals with are complex. PKI provides a means of linking an identity in the physical world with an online identity. The concept of identity in the physical world is very complex. A given name may correspond to many people and a single person may use many names. Naming of corporations is even more complex. The name Rolls Royce is for most people synonymous with luxury automobiles, but Rolls Royce Plc., which owns the Rolls Royce trademark actually makes aircraft engines.

Attempts to produce a “simple” PKI have invariably ended up merely transferring complexity from one place to another, often increasing the difficulty of the task in the process. For this reason, XKMS does not attempt to eliminate the complexity of PKI; instead it allows that complexity to be transferred from a place where it is hard to manage (the application client) to a managed service that can specialize in PKI management.

XKMS is a Web Service that provides an interface to a PKI. An application accessing a PKI through an XKMS service is shielded from the complexities of the underlying PKI (see the following illustration). In effect, the complexity of the PKI is transferred from the client to the XKMS service.

Tip

One of the most difficult to implement parts of a PKI is the user interface. Shielding the application from the complexity of PKI allows the user to be likewise shielded from complex configuration panels.

Moving the complexity of PKI management from the application to the XKMS service has many advantages. It is worth spending some time on these advantages because the problems of PKI deployment addressed by XKMS are common to a great many e-commerce applications, and the advantages of XKMS are in many cases the advantages of the Web Services architecture.

Reduced Client Complexity

One of the original design goals for XKMS was to allow handheld devices such as the then planned Microsoft Pocket PC to have full access to PKI functionality, despite limited memory and user interface capabilities. An XKMS client interface library may be coded in a few thousand lines of code on a machine that already provides the necessary XML and SOAP support. Even a partial implementation of the PKIX specification is likely to involve a hundred times that amount of code.

Ease of Coding

Traditional PKIs became so complex that the ease of coding ceased to be a major concern in their design. It was assumed that application developers would use some form of toolkit or operating system layer to support PKI functions. This approach had many disadvantages, not least the fact that the PKI toolkits tended to be developed by PKI vendors—and consequently tended to be rather better at interconnecting to PKI products sold by the vendor that wrote it than being a strictly correct implementation of the PKIX standard. Another disadvantage is that toolkits only eliminate the need to implement complex functionality; the need to test remains as does the need to provide a user interface. In many cases, these tasks are made more difficult as the toolkit implementation may be more complex than is strictly necessary for the implementation.

Although we present examples in this chapter of using the VeriSign Trust Service Integration Kit (TSIK), a full-featured XKMS client implementation may be written and tested in under a week if necessary.

The Client Deployment Problem

As the use of PKI has grown, the sophistication of the PKIX specification has increased considerably. Application support for these more sophisticated features has progressed at a much slower rate. One of the reasons for this slow pace of adoption has been that a PKI feature has little value until it is widely deployed, because any client that relies upon support for that feature will only be able to communicate within a very narrow circle. This creates a vicious circle—the feature has no value until it is widely supported, and application developers are understandably reluctant to add complex features to their programs that have little immediate value.

Even after a developer agrees to add support for a feature, there is a considerable delay before deployment becomes widespread. The product cycles of the major application vendors typically introduce a minimum delay of two years between adding a feature to the product requirements and the product reaching the market. There is then a further delay as the new products gradually replace the old. The cumulative effect of these delays is that deployment of a new PKI feature will typically take about ten years from initial design to the point where deployment is widespread enough for applications to rely on support.

XKMS removes the complexity of PKI from the client and transfers it to a trust service. This allows new PKI features to be deployed without making modifications to already deployed clients.

Tip

XKMS is an ideal solution if some form of PKI support is required in an embedded device such as a router for a virtual private network. Such devices are required to be “install and forget” since customers do not want to have to regularly upgrade or replace them to keep up with developments in PKI technology.

Centralized Trust Management

Next to the problem of deploying PKI clients with the necessary features, the most common complaint from enterprises attempting to deploy (particularly) large PKIs is the complexity of configuring the clients to apply the enterprise security policy. XKMS allows PKI configuration to be managed as an enterprise resource rather than being left to individual user preferences. This is frequently essential if the PKI is going to be successful, because the preference of many end users is frequently to disable security altogether.

This feature of XKMS has drawn some criticism. One of the core doctrines of modern security protocol design is the end-to-end principle pioneered by MIT. That is, if Alice sends an e-mail message to Bob, the cryptography protecting the message should be applied in the device that Alice uses to generate the message (the sending end) and only removed in the device Bob uses to receive the message (the receiving end). According to the end-to-end principle, Alice and Bob should rely on the cryptography they control rather than the network to provide security.

The end-to-end principle has traditionally treated PKI as if it were simply another processing step and therefore something the end users should configure for them- selves in each device they own. This first came into question in enterprise deployments, where the PKI is intended to implement the enterprise security policy rather than the personal preferences of individual employees. The “ends” of the communication may be in the devices, but the ends of the trust relationships are the enterprises that employ Alice and Bob rather than Alice and Bob themselves.

As devices with embedded PKI features start to become ubiquitous, the need for some form of centralized PKI management is becoming apparent even in consumer applications. Most consumers are likely to opt to have their PKI management performed for them by a specialist—in most cases as a service delivered through their network provider. The few consumers who have the inclination and necessary expertise to configure their own PKI can achieve full control through their own XKMS services.

Tip

Consider adding XKMS support to an application even if you intend to provide comprehensive native support for PKIX/X.509. Doing so will allow your customers to make their own choices with respect to PKI configuration rather than rely on the choices you make for them.