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.
Origins of XKMS
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
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.
Goals of XKMS
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.
The X-KISS Locate service resolves a
9.6 XKMS message types and their relationship to the
XKMS client and the Trust Service.
Here's a sample scenario: A Web service receives a signed document that specifies the sender's X.509v3 certificate but not the key value (which is embedded in the X.509 certificate). The Web service is not capable of processing X.509v3 certificates but can obtain the key parameters from the XKMS service by means of the Locate service. The Web service sends the
Listing 9.7 X-Kiss Request to XKMS Locate Service to Process X.509 Certificates to Obtain Key Parameters
When the Locate service receives the X.509v3 certificate from the
Listing 9.8 Response from XKMS Locate Service to Preceding Request
The X-KISS Validate service performs this function, and in addition, the client may obtain an assertion from the X-KISS service specifying the status of the binding between the public key and other data—for example, a name or a set of extended attributes. Furthermore, the service represents that the status of each data element returned is valid and that all are bound to the same public key. The client sends to the XKMS service a prototype containing some or all of the elements for which the status of the key binding is required. If the information in the prototype is incomplete, the XKMS service may obtain additional data required from an underlying PKI Service, as depicted in Figure 9.7. After the validity of the Key Binding has been determined, the XKMS service returns the status result to the client.
Figure 9.7 The Validate service provides key validation usually
sitting on top of a PKI at a trusted third party.
No single set of validation criteria is appropriate to every circumstance. Applications involving financial transactions are likely to require the application of very specific validation criteria that ensure certain contractual and/or regulatory policies are enforced. The Locate service provides a key discovery function that is neutral with respect to the validation criteria that the client application may apply. The Validate service provides a key discovery and validation function that produces results that are specific to a single set of validation criteria.
From a Web services point of view, Locate and Validate will be the most common form of XKMS service requested. Depending on the nature of the Web service provided and the security policy in place, X-KRSS messages such as Register, Recover, Revoke, and Reissue may be processed only under a much more stringent environment.
In the registration phase, as shown in Figure 9.8, an XML application key pair holder registers its public key with a trusted infrastructure via a registration server. The public key is sent to the registration server using a digitally signed request specified by KRSS using the
Figure 9.8 X-KRSS key registration.
A sample X-KRSS
Listing 9.9 X-KRSS Request to XKMS Registration Service for Key Registration
Listing 9.10 X-KRSS Response from the XKMS Registration Service
Revocation is handled via a similar protocol. The use of desktop (that is, file system) private key storage—as well as more broad XML client encryption applications—mandates some form of key recovery provision. Key recovery provides a way to recover a lost private key so that corporate-owned data encrypted with the lost private key is not lost forever. For historical reasons, key recovery is not supported by standardized protocols. In X-KRSS, such support is built in.