The XKMS protocol follows a request/response mechanism. Each request is followed by a response message. Apart from the Authenticate message, all other messages can be grouped under one of the following message types:

The relationship of these messages to the requesting XKMS client and the responding Trust Service is shown in Figure 9.6.

The X-KISS Locate service resolves a <ds:Keyinfo> element. It is a name resolution service. The service may resolve the <ds:Keyinfo> element using local data or may relay the request to other servers. For example, the XKMS service might resolve a <ds:RetrievalMethod> element or act as a gateway to an underlying PKI based on a non-XML syntax.

Figure 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 <ds:Keyinfo> element to the Locate service and requests that the <KeyName> and <KeyValue> elements be returned, as shown in Listing 9.7. When it has these elements, it has the information needed to decode the XML Digital Signature it just received.

Listing 9.7 X-Kiss Request to XKMS Locate Service to Process X.509 Certificates to Obtain Key Parameters

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Id="I4593b8d4b6bd9ae7262560b5de1016bc"
   Service="http://test.xmltrustcenter.org/XKMS"
   xmlns="http://www.w3.org/2002/03/xkms#">
 <RespondWith>KeyValue</RespondWith>
 <QueryKeyBinding>
  <ds:KeyInfo>
   <ds:X509Data>
    <ds:X509Certificate>MIICAjCCAW+gAwIBAgIQlzQov
IEbLLhMa8K5MR/juzAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc3QgQ0EwHhcNMDIwNjEzMjEzMzQ
xWhcNMzkxMjMxMjM
1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFsaWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJK
oZIhvcNAQEBBQADg
Y0AMIGJAoGBAMoy4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctC
WbeqR5a40JCQmvN
mRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr4fSYpP
ELOH5PDJEBAgMBA
AGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAwDgYDVQQDEwdUZXN0IENBghBy
sVHEiNFiiE2lxWv
mJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIbooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfm
p9GoN08Jkurx/gF
18RFB/7oLrVY+cpzRoCipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0Xktmv
NzcJDes9PMNxrVt
ChzjaFAE=</ds:X509Certificate>
   </ds:X509Data>
  </ds:KeyInfo>
  <KeyUsage>Signature</KeyUsage>
 </QueryKeyBinding>
</LocateRequest>

When the Locate service receives the X.509v3 certificate from the <LocateRequest> in Listing 9.7, it extracts the key information from the certificate and constructs the elements it needs to return from the requesting service, as shown in Listing 9.8.

Listing 9.8 Response from XKMS Locate Service to Preceding Request

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Id="I46ee58f131435361d1e51545de10a9aa"
   Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
   RequestId="#I4593b8d4b6bd9ae7262560b5de1016bc"
   xmlns="http://www.w3.org/2002/03/xkms#">
 <UnverifiedKeyBinding Id="I36b45b969a9020dbe1da2cb793016117">
  <ds:KeyInfo>
   <ds:KeyValue>
    <ds:RSAKeyValue>

<ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbS
hPMRp1qFrAfF13L
MmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNlqM2Ph9XWMc
c7qbjNHw8=</ds
:Modulus>
     <ds:Exponent>AQAB</ds:Exponent>
    </ds:RSAKeyValue>
   </ds:KeyValue>
  </ds:KeyInfo>
  <KeyUsage>Signature</KeyUsage>
  <KeyUsage>Encryption</KeyUsage>
  <KeyUsage>Exchange</KeyUsage>
 </UnverifiedKeyBinding>
</LocateResult>

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.

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.