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.

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 <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.

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 XKMS Services

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:

Locate	This message provides name resolution.
Validate	This message provides key validation.
Register	Information is bound to a public key pair through a key binding.
Reissue	A previously registered key binding is reissued.
Recover	A previously registered key binding that may have been lost is recovered.
Revoke	A previously registered key binding is revoked .

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

Figure 9.6. XKMS message types and their relationship to the XKMS client and the Trust Service.

X-KISS

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.

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.

X-KRSS

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 <Register> tag. The registration server responds with an XML formatted confirmation response using the <RegisterResponse> tag, which indicates status of the registration (accepted, rejected, or pending) and a confirmation of name and attribute information registered with the public key. Except in the case of rejection , a key pair identifier is returned in the <RegisterResponse> tag for subsequent referencing purposes. The registration is typically preceded by generation of the key pair in the key pair holder system.

Figure 9.8. X-KRSS key registration.

A sample X-KRSS <Request> is shown in Listing 9.9.

Listing 9.9. X-KRSS Request to XKMS Registration Service for Key Registration

 <?xml version="1.0"?>  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"  xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">    <soap:Body>      <Register xmlns="http://www.xkms.org/schema/xkms-2001-01-20">        <Prototype>          <Status>Valid</Status>          <KeyID>mailto:[e-mail]</KeyID>             <ds:KeyInfo>               <ds:KeyName>mailto:[e-mail]</ds:KeyName>             </ds:KeyInfo>          <ValidityInterval>            <NotBefore>2000-09-20T12:00:00</NotBefore>            <NotAfter>2001-09-20T12:00:00</NotAfter>          </ValidityInterval>          <PassPhrase>qfarJIsfcVKLo</PassPhrase>        </Prototype>        <AuthInfo>          <AuthUserInfo>            <ProofOfPossession>              <Signature>2PUN8HQlnhf9YI</Signature>            </ProofOfPossession>            <AuthKeyBinding>              <Signature>EfdxSXAidruAszN</Signature>            </AuthKeyBinding>          </AuthUserInfo>        </AuthInfo>        <Respond>          <string>KeyName</string>          <string>KeyValue</string>        </Respond>      </Register>    </soap:Body>  </soap:Envelope> 

The X-KRSS <RegisterResult> response to this request is shown in Listing 9.10.

Listing 9.10. X-KRSS Response from the XKMS Registration Service

 <?xml version="1.0"?>  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"  xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">    <soap:Body>      <RegisterResult xmlns="http://www.xkms.org/schema/xkms-2001-01-20">        <Result>Success</Result>        <Answer soapenc:arrayType="KeyBinding[1]">          <KeyBinding>            <Status>Valid</Status>            <KeyID>mailto:[e-mail]</KeyID>              <ds:KeyInfo>                <ds:KeyValue>                  <ds:RSAKeyValue> <ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJ IsfcVKLob1hGnQ/l6xw==</ds:Modulus>                    <ds:Exponent>AQAB</ds:Exponent>                  </ds:RSAKeyValue>                </ds:KeyValue>                <ds:KeyName>mailto:[e-mail]</ds:KeyName>              </ds:KeyInfo>            <ValidityInterval>              <NotBefore>2000-09-20T12:00:00</NotBefore>              <NotAfter>2001-09-20T12:00:00</NotAfter>            </ValidityInterval>          </KeyBinding>        </Answer>        <Private/>      </RegisterResult>    </soap:Body>  </soap:Envelope> 

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.