XKMS does the heavy work of PKI

An upcoming standard from the World Wide Web Consortium aims to reduce the costs of PKI without sacrificing its benefits.

Public-key infrastructure is well suited for securing Web services, but PKI deployment is too cumbersome and costly for the technology to achieve widespread use. An upcoming standard from the World Wide Web Consortium aims to reduce the costs of PKI without sacrificing its benefits.

XML Key Management Specification (XKMS) borrows the best of PKI without reducing scalability or security. XKMS creates a trust service that shields clients from complexity by providing an XML interface to PKI. The proposed standard is in the last-call phase with the W3C and several vendors are starting to develop XKMS toolkits and applications.

PKI scales well because it does not require an online service such as Kerberos Key Distribution Center. Because Kerberos uses shared-secret cryptography, it’s a likely target for hacker attacks. And because it contains so much sensitive information, it is usually not widely replicated, making it a potential single point of failure.

PKI avoids both of these issues by using a set of public and private keys: Private keys are held only by an individual party; public keys can be distributed widely. With a PKI-secured message, an online service such as the KDC is not needed for any two parties to communicate securely. In addition, the ability to have a hierarchical key structure, and real-time analysis of the path through the hierarchy, makes it possible for parties to securely communicate without prior business arrangement.

With XKMS, a client and application server share an XKMS service to validate each other and to process requests between them. XKMS replaces many PKI protocols and data formats, such as Certificate Revocation Lists, Online Certificate Status Protocol, Lightweight Directory Access Protocol, Certificate Management Protocol and Simple Certificate Enrollment Protocol, with one XML-based protocol. XKMS also can be implemented client-to-client, server-to-client, server-to-server, and so forth.

The XKMS protocol provides three fundamental operations: locating which retrieves a cryptographic key so that it can communicate securely with another entity; validating, which makes sure the key is active and has not been revoked; and registering, which issues, reissues and revokes keys.

Unlike an XKMS service, PKI requires that every user and every application verify the identity of everyone they communicate with and ensure that the counter-party identity is appropriate for the transaction and that the identity is still valid (not been revoked). Unfortunately, the infrastructure needed to support this places such burdensome demands on application developers that it is difficult to develop a secure application that achieves these goals.

Traditionally, with PKI all trust decisions are offloaded to the crypto consumer. This requires complicated programming libraries and configuration information. For an example of this, look at the “trusted issuers” list in the security parameters section of your Web browser.

With XKMS, trust decisions are given to a common server so they can be centralized and applied consistently across platforms. The only configuration information an XKMS client needs is the URL of the server, and the certificate the server will be using to sign its replies. Different trust models can be supported by using different URLs.

XKMS works with the XML Digital Signature and Encryption standards. For example, the Locate and Validate operations take a element. This means that a message receiver can verify the identity of the sender by “plucking out” the element, putting it in an XKMS call and looking at the server’s response. The server can respond with just the cryptographic key (for doing the signature math on small devices such as cell phones); a user-friendly name for the key (for example, rsalz@datapower.com, for use in browsers and Web pages); an assertion about the validity of the key (such as it has not been revoked); or a combination of the three.

Many XML Web services standards, including Security Assertions Markup Language and WS-Security , use digital signatures to protect the content of authentication and message data. Although it has not yet received the publicity that those specifications have received, XKMS might be the specification that makes Web services implementation feasible.

Salz is chief security officer for DataPower Technology and a member of the WS-Security and XKMS working groups. He can be reached at rsalz@datapower.com.