Note: Click this link to see part one of this chapter.

XML Key Management Specification (XKMS)

The XML Key Management Specification is built on top of and complements the XML standards for Digital Signature and Encryption. XKMS reached version 2.0 W3C working draft in April 2003.

By now, you see that Web services need end-to-end message integrity and confidentiality, which means that they need XML Digital Signature and XML Encryption. Those technologies, in turn, scale best when they use public key cryptography. Public key cryptography needs a supporting infrastructure, PKI, to handle distribution, certification, and life-cycle management (for example, revocation) of keys. PKI has proven to be very difficult and expensive to build and maintain in practice, and many failures have given it a bad reputation as an almost "failed" technology. Web services themselves provide a powerful new approach to PKI that prevents each Web service requestor and provider from having to build their own PKI: accessing a trusted PKI as a service. XKMS aims to do just that.

XKMS specifies protocols for distributing and registering public keys suitable for use in conjunction with the XML Digital Signature standard and the XML Encryption standard. XKMS is composed of two parts:

• XML Key Information Service Specification (X-KISS)

• XML Key Registration Service Specification (X-KRSS)

X-KISS is a protocol to support the creation of a service to which an application delegates the processing of Key Information. Thus, applications needing keys for use with an XML Signature, XML Encryption, or other use of the <ds:KeyInfo> element can handle the necessary complex key management by calling a shared service.

X-KRSS is a protocol to support the registration and management of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure such as X.509 or PKIX.

XKMS's first goal is to support a simple client's capability to use sophisticated key management functionality. Such a simple client is not concerned with the details of the infrastructure required to support the public key management but may choose to work with X.509 certificates if it is able to manage the details. This ties back to the biggest impediment for PKI, which has been the lack of client support. This goal does not directly impact the discussion of PKI for Web services, but the second goal does.

The second goal is to provide public key management support to XML applications. In particular, it is a goal of XML key management to support the public key management requirements of XML Encryption, XML Digital Signature, and to be consistent with SAML.

One sample use of XKMS is for implementing "transaction accountability." When a Web service embeds trust in electronic transactions using digital signatures, digital receipts, and notary services based on business policies, XKMS can, when needed, transparently link to a trust Web service to affix and validate digital signatures, notary stamps, and digital receipts to XML documents.

In this scenario, XKMS represents a strong tangible benefit of XML Signature. The presence of XKMS means that use of XML Signature can be independent of PKI vendor implementations and enables Web services to offer a wider range of options for trust relationships. In particular, access to an XKMS service makes it easier to add attribute-bindings to messages than it would be to add X.509 certificate extensions that require a tight relationship with a PKI vendor.

This chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today. Buy this book now.