Getting Started with XML Security

Key Management: XML Key Management Specification (XKMS)

Purpose and Benefits

The XML Key Management Specification (XKMS) [ XKMS ] defines protocols for Public Key management services. Public Key management includes the creation of a public and private key pair, the binding of this key pair with identity and other attributes, and the representation of this key pair in different formats, such as by key name, digital certificate or key parameters, to give some examples. Public key technology is an essential part of XML Digital Signatures, XML Encryption and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt. In either case the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encrypting for recipients.

Public Key management usually requires a registration step in which the key pair is generated and some sort of token is issued to associate the public key with the identity and other attributes of the owner. This registration step usually incorporates some sort of due diligence to reduce the risks of associating the public key incorrectly, since people will rely upon the key pair later. Management also includes the ability to revoke the association of information with the key pair should circumstances change, such as the theft of the private key or a change in the owner's attributes (no longer an employee, for example). Likewise, information bound to the key pair may be updated. Traditionally, such bindings were managed using X.509 Digital Certificates, specialized protocols and public key infrastructures. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This eliminates the need for applications to support other specialized public key registration and management protocols.

Once registration is complete, a public key pair may be used for signing and verification or encryption and decryption. The <KeyInfo> element defined in the XML Digital Signature recommendation may be used to provide information to the recipient of a digital signature or encrypted data block about the key needed to process that content. This information may take on a number of different forms, such as a key name, a digital certificate containing the public key, a set of key parameters, or a URI indicating where to obtain the public key. Given the variety of choices for providing information about a key to a recipient, it may be hard for an application to process and locate a key. In addition to the difficulty of anticipating all formats, some, such as X.509 certificates, require special cryptographic code and logic for processing. XKMS provides an XML message format to allow this processing to be performed by a service which will sort through the various options, determine the one that was used, and provide the key information to the recipient in a useful form.

Features

The XML Key Management Specification (XKMS) defines three specifications:

• XML Key Registration Service Specification (XKRSS),
• XML Key Information Service Specification (XKISS)
• Protocol Bindings

These specifications define the XML request and response messages necessary for registering and managing information associated with public keys and for ensuring that security requirements are met.

The registration service supports the binding of information with a public key pair, either one generated by the server or by the client. The binding associates information with the key pair, creating a <KeyBinding> element. This binding may have a validity period associated with it and may be reissued or revoked. The private key associated with a key binding may also be backed up recovered if the local copy is destroyed (as when an operating system requires reinstallation).

The key information service allows a client to request information associated with a <KeyInfo> element. This may include:

1. Locate - Resolve the <KeyInfo> element to return requested key information


2. Validate - Locate key information and provide an assertion on the validity of the binding to the key pair.

A key information request may specify the form of key information to be returned. For example, it may request that a <KeyName> and <KeyValue> be determined from a <KeyInfo> element. As part of this process, the server may perform validation to assert the validity of the binding to the key.

The Protocol Bindings specification defines mechanisms for meeting security requirements, including mechanisms to ensure message confidentiality, integrity, and security. This includes the following definitions:

• A two phase protocol to avoid replay attacks
• Pending response protocol
• Use of payload security
• Use of transport security such as SSL/TLS
• Use of Web Services security (see below)

Key Concepts

Important points about the XKMS specification are:

1. This specification defines XML protocol messages to convey key registration and information requests to a trust server and to convey responses from the server. The specification defines a binding of these messages to the XML Protocol (SOAP) and defines the relationships among the messages using the Web Services Definition Language (WSDL).
2. <ds:KeyInfo> processing is delegated to the trust service by the client, minimizing the complexity of the client. How the trust service is implemented is dependent on the service, but acting as a front-end to a public key infrastructure (PKI) is one possibility.
3. The XML Key Information Service Specification (XKISS) includes online status functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate functionality.
4. Registration supports the requirements of smart card manufacturing, including bulk processing and pending responses.
5. The specification supports the use of XML Digital Signatures for message integrity and authentication. The specification also defines other authentication mechanisms, support for proof of key ownership and other security functionality.
6. A Locate or Validate request may include a <KeyInfo> element and <RespondWith> element in the request. The <RespondWith> element is used to specify what the <KeyInfo> element is to be resolved to, possibly more than one item. For example, the request <KeyInfo> might contain an X.509 certificate and the <RespondWith> might indicate that the KeyName and KeyValue are to be returned. Possibilities include KeyName, KeyValue, and Certificate, Certificate Chain (collection of certificates needed to trace a signature back to a trusted party) among the possibilities outlined in the specification.
7. A <KeyBinding> element is used to associate information with a key. This is what is returned in a Locate or Validate response. Every <KeyBinding> includes a <ValidityInterval> (NotBefore, NotOnOrAfter) and may also include <KeyInfo>, <ProcessInfo> (opaque data), <KeyUsage> and <UseKeyWith> elements.


8. Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.


9. A <KeyBinding> <UseKeyWith> element defines which application and application entity the key is intended for. For example, a key may only be appropriate for authentication of an SSL server. In this case, the application is HTTPS, and the identifier is the URL of the server. Applications listed in the specification include S/MIME, HTTPS, SMTP, IPSec, PKIX and others.

Examples

A client might generate a key pair and wish to register it with a trust server, as in this example. (Complete examples are provided with the XKMS specification):

<RegisterRequest      
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
 Service="http://test.xmltrustcenter.org/XKMS"      
 RequestId="hZMRGyATbUL4H7rYOanR6Q=="      
 xmlns="http://www.w3.org/2002/03/xkms#">      
 <RespondWith>X509Cert</RespondWith>      
 <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">      
   <KeyInfo>      
     <ds:KeyValue>      
       <ds:RSAKeyValue>      
         <ds:Modulus>      
           zvbTdKsTprGAKJdgi7ulDR0eQBptL...      
         </ds:Modulus>      
         <ds:Exponent> AQAB </ds:Exponent>      
       </ds:RSAKeyValue>      
     </ds:KeyValue>      
   </KeyInfo>      
         
   <KeyUsage>Signature</KeyUsage>      
   <UseKeyWith      
     Application="urn:ietf:rfc:2633"      
     Identifier="alice@alicecorp.test" />      
 </Prototype>      
 <Authentication>      
   <ProofOfPossession>      
     <ds:Signature>      
       signing with the private key      
       demonstrates possession of it      
     </ds:Signature>      
   </ProofOfPossession>      
 </Authentication>      
</RegisterRequest>
Example 8 - XKMS Register Request

The server responds with the information requested with <RespondWith>:

<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
               Service="http://test.xmltrustcenter.org/XKMS"      
               ResultMajor="Success"      
               RequestId="hZMRGyATbUL4H7rYOanR6Q=="      
               ResponseId="k9gyjDdhLLV1vbF7RzJjIw=="      
               xmlns="http://www.w3.org/2002/03/xkms#">      
   <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">      
       <KeyInfo>      
          <KeyName>Sally Smith key</KeyName>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
       Identifier="alice@alicecorp.test" />      
   </KeyBinding>      
</RegisterResult>
Example 9 - XKMS Register Response

A client could request an identity validation:

<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"      
                Service="http://test.xmltrustcenter.org/XKMS"      
                RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="      
                xmlns="http://www.w3.org/2002/03/xkms#">      
   <RespondWith>KeyName</RespondWith>      
   <RespondWith>KeyValue</RespondWith>      
   <RespondWith>Multiple</RespondWith>      
   <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">      
       <KeyInfo>      
           <ds:X509Data>      
               <ds:X509Certificate>      
                   certificate encoded as text      
               </ds:X509Certificate>      
           </ds:X509Data>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
                   Identifier="alice@alicecorp.test" />      
   </KeyBindingQuery>      
</ValidateRequest>
Example 10 - XKMS Validate Request

The following response indicates that the certificates are valid:

<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
               xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"      
               Service="http://test.xmltrustcenter.org/XKMS"      
               ResultMajor="Success"      
               RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="      
               ResponseId="0WeinJVdbyBKruXhiqTscg=="      
               xmlns="http://www.w3.org/2002/03/xkms#">      
   <KeyBinding Id="m0/p5bekjemI4tV+FPBkig==">      
       <KeyInfo>      
           <ds:KeyValue>      
               <ds:RSAKeyValue>      
                   <ds:Modulus>...</ds:Modulus>      
                   <ds:Exponent>AQAB</ds:Exponent>      
               </ds:RSAKeyValue>      
           </ds:KeyValue>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
                   Identifier="alice@alicecorp.test" />      
       <Reason>IssuerTrust</Reason>      
       <Reason>RevocationStatus</Reason>      
       <Reason>ValidityInterval</Reason>      
   </KeyBinding>      
</ValidateResult>
Example 11 - XKMS Validate Response