XML Key Management System (XKMS) | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

XML Key Management Service (XKMS) specifications form the basis for registration, subscription, and management of keys in XML Web services. XKMS facilitates PKI Key management functionality and services such as certificate issuance, processing, validation, revocation, status checking, and so forth. These services are suitable for use in conjunction with XML Signature and XML Encryption. XKMS enables offloading of PKI functionalities to remote trust service providers. XML Web services developers need to know only how to invoke these remote services by locating, registering, and subscribing to the services. XKMS has emerged from the W3C as an industry-standard initiative for defining protocols for distributing, registering, and processing public keys to support the use of XML Signature and XML Encryption in Web services.

To find out the current status of XKMS specifications from the W3C working group, refer to the W3C Web site at http://www.w3.org/TR/xkms.

Motivation of XKMS

PKI is based on public-private key pairs and has been used for securing business application infrastructures and transactions. Private keys are used by the service provider application and public keys can be distributed to the clients. In the case of Web services, the use of XML encryption and XML signature required integration with a PKI-based key solution to support related key management functionalities such as encryption, decryption, signature verification, and validation. There are a variety of PKI solutions, such as X.509, PGP, SPKI, and PKIX, available from multiple vendors.

In the case of Web services, using PKI solutions from multiple vendors mandates interoperability. For example, company A encrypts and signs its messages using an X.509 PKI solution from vendor A and communicates with company B using a different PKI solution from vendor B. In this scenario, company B's PKI solution fails to verify and is unable to decrypt the message sent by company A. This has become a problem in securing Web services due to the issues of interoperability and managing cryptographic keys.

XKMS introduces an easy solution for managing PKI-related functionalities by offloading PKI from applications to a trusted service provider. The trusted service provider facilitating XKMS service "under the hood" provides a PKI solution. This means that client applications and Web services relying on XKMS do not require a PKI solution. Instead, they delegate all PKI-related responsibilities to an XKMS provider (trusted service) and issue XML-based requests for obtaining PKI services from them.

XKMS Specification Overview

The XKMS specification defines an XML-based protocol for distributing and registering PKI-based cryptographic keys for use in Web services. It defines a set of PKI services that adopt standards-based protocol bindings, syntax, and processing rules. XKMS is implemented by a trust service provider that allows its subscribers to register and access its required PKI functions. To support the use of XML signature and XML encryption in Web services, XKMS allows an application or user using a public key to verify a digital signature, to encrypt data, or to locate that public key as well as other information pertaining to its communicating peer. The client application making the request does not need to know the details of the PKI solution hosted by the trust service.

The XKMS specification is made up of two parts: X-KISS (XML key information service specification) deals with retrieval and processing of key information and X-KRSS (XML key registration service specification) deals with registration of public keys.

XML Key Information Services (X-KISS)

X-KISS defines a protocol for delegating and processing of PKI-related functions associated with XML signature and XML encryption to a XKMS-based trust service provider. By delegating to a trust service, it reduces the complexity of using PKI to establish trust relationships with a Web services provider or requesters and avoids interoperability-related issues. X-KISS supports processing of <ds:KeyInfo> elements that specify information about the key used for encrypting the data in an XML signature and an XML encryption. In an XML signature, the signer of the XML document includes <ds:KeyInfo> to specify the key identification details, such as the <ds:KeyName> element that specifies the key name and the <ds:RetrievalMethod> element for specifying the location of the key information.

X-KISS provides support for two types of service: locate service and validate service.

X-KISS Locate Service

The locate service allows you to locate and retrieve public keys by resolving the <ds:KeyInfo> element. The required key information may be available as part of the message as child elements <ds:KeyName> and <ds:RetrievalMethod> that specify the name and location of the key information, respectively.

Figure 6-4 is a sequence diagram illustrating the X-KISS locate service, where a Web service sends an XML request to a trust service provider to locate the key and obtains the key value. The Web services requester (or provider) receives a signed XML document from the XKMS trust service that contains a <ds:Keyinfo> element. The <ds:KeyInfo> element specifies a <ds:RetrievalMethod> child element that mentions the location of an X.509 certificate that contains the public key. The application sends an XML request to the trust service that specifies the <ds:Keyinfo> element and in return, the trust service sends a response that specifies the <KeyName> and <KeyValue> elements.

Figure 6-4. X-KISS locate service

Example 6-28 represents an XML request to a trust service to locate the key information. The <Locate> element contains the complete query for locating the key. The child element, <Query>, contains the <ds:KeyInfo> that may hold either a <ds:KeyName> or <ds:RetrievalMethod>. The <Respond> element specifies the required return values, such as the <KeyName> and the <KeyValue>.

Example 6-28. Representation of XML request to a XKMS trust service

  <Locate>      <Query>           <ds:KeyInfo>             <ds:KeyName>CSP Security</ds:KeyName>           </ds:KeyInfo>      </Query>      <Respond>           <string>KeyName</string>           <string>KeyValue</string>      </Respond> </Locate>

Example 6-29 shows the representation of the XML response from the trust service, which provides the result, including the key name and key value.

Example 6-29. Representation of XML response from a XKMS trust service

   <LocateResult>       <Result>Success</Result>         <Answer>           <ds:KeyInfo>                <ds:KeyName>                     O=CSP, CN="CSP Services"                </ds:KeyName>                <ds:KeyValue>soijhfsdhsdf+h===</ds:KeyValue>             </ds:KeyInfo>           </Answer>        </LocateResult>

In this response, the <LocateResult> element contains the complete response from the trust service, the child element <Result> contains the response; it can be either success or failure. The <Answer> element specifies the actual return values, such as the <KeyName> that mentions the name and the <KeyValue> holding an X.509 certificate.

X-KISS Validate Service

The X-KISS validate service searches the trust service provider for the public key defined in the <ds:KeyInfo> element. It returns a response that provides an assertion to the client about the validity of the binding between key name and key, and its trustworthiness. Let's take a look at a simple scenario in which the application sends a request that specifies the <ds:Keyinfo> element to the trust service and that requests validation of the status of the binding information. Example 6-30 shows the sample representation of the XML request to validate the binding status.

Example 6-30. Representation of XML request to validate the key status

<Validate>      <Query>          <Status>Valid</Status>           <ds:KeyInfo>                <ds:KeyName>CSP Security</ds:KeyName>                <ds:KeyValue>...</ds:KeyValue>           </ds:KeyInfo>      </Query>      <Respond> <string>KeyName</string> <string>KeyValue</string>     </Respond> </Validate>

In this representation, the <Validate> element contains the complete query for validating the binding information, and the child element <Query> contains the <ds:KeyInfo> or a <ds:KeyName>. The <Respond> element specifies the required return values, such as the <ds:KeyName> and the <ds:KeyValue>.

Example 6-31 shows the representation of the XML response from the trust service, which mentions the status of the binding between the <ds:KeyName> and <ds:KeyValue> and its validity.

Example 6-31. Representation of XML response about a key validity

<ValidateResult>      <Result>Success</Result>      <Answer>           <KeyBinding>                <Status>Valid</Status>                <KeyID>                   http://www.csp-xkms.org/assert/8676-986-80                </KeyID>                <ds:KeyInfo>                     <ds:KeyName>...</ds:KeyName>                     <ds:KeyValue>...</ds:KeyValue>                </ds:KeyInfo>                <ValidityInterval>                     <NotBefore>                          2000-09-20T12:00:00                     </NotBefore>                     <NotAfter>                          2005-10-20T12:00:00                     </NotAfter>                </ValidityInterval>           </KeyBinding>      </Answer> </ValidateResult>

In this response, the <ValidateResult> element contains the complete response from the trust service, and the child element, <Result>, contains the response, which can be either success or failure. The <Answer> element specifies the actual return values in the child element <KeyBinding>, defining the key id <KeyID>, key information <KeyInfo>, and validity <ValidityInterval> as its child elements.

XML Key Registration Service (X-KRSS)

The X-KRSS specification defines a protocol that provides public-key management services of an XKMSbased trust service provider. X-KRSS handles the entire life-cycle functions of a public key, including:

Registration: The registration service registers a key pair and its associated binding information.
Revocation: The revocation service revokes the status of previously issued keys (valid keys).
Recovery: The recovery service recovers the private key associated with key binding.
Reissue: The reissue service is quite similar to the registration service that allows the reissue of previously issued key bindings.

The ultimate goal of the X-KRSS specification is to deliver a complete XML-aware PKI management protocol providing these life-cycle operations.

X-KRSS Key Registration Service

The key registration service defines an XML-based protocol for registration of public-key information. It allows an XML-aware application to register its public-key pair and its associated binding information to an XKMS trust service provider. The key pair may be generated by the client application or by the XKMS trust service. To register a key pair, the client application typically sends a signed request to the XKMS trust service using an X-KRSS request format. The XKMS trust service responds and confirms the status of the registration. At the time of registration, the service may require the client application to provide a key pair along with additional information pertaining to authentication. Upon receipt of a registration request, the service verifies the authentication credentials and Possession of Private (POP) key information of the client and then registers the key and associated binding information.

Let's consider a scenario in which an application sends a request to register its client-generated public-key pair and binding information with an XKMS trust service provider. Example 6-32 shows the representation of the X-KRSS registration request to the XKMS trust service provider.

Example 6-32. X-KRSS registration request to an XKMS trust service

<Register>      <Prototype >           <Status>Valid</Status> <KeyID> http://www.cspsecurity.com/myapplication </KeyID>           <ds:KeyInfo>                <ds:KeyValue>                     <ds:RSAKeyValue>                          <ds:Modulus>...</ds:Modulus>                          <ds:Exponent>...</ds:Exponent>                     </ds:RSAKeyValue>                </ds:KeyValue>             <ds:KeyName> http://www.cspsecurity.com/myapplication?company=csp;CN=web    </ds:KeyName>           </ds:KeyInfo> <PassPhrase>70lkjwer-94-09i-0</PassPhrase>      </Prototype>      <AuthInfo>           <AuthUserInfo>                <ProofOfPossession>      <ds:Signature URI="#mykeybinding" [RSA-Sign (KeyBinding, Private)] />                </ProofOfPossession>                <KeyBindingAuth>  <ds:Signature  URI="#mykeybinding" [HMAC-SHA1 (KeyBinding, Auth)] />                </KeyBindingAuth>           </AuthUserInfo>      </AuthInfo>      <Respond>           <string>KeyName<string>           <string>KeyValue</string>           <string>RetrievalMethod</string>      </Respond> </Register>

In Example 6-32, the complete registration request is identified by the <Register> element. The <Prototype> element represents the prototype of the key and binding information. Because the request is intended for the registration of a client-generated key pair, it contains the key value information as part of the <ds:KeyInfo> element. The <PassPhrase> element provides the information for authenticating the client with the service provider. During registration, the <AuthInfo> element provides the data that authenticates the request, mentioning the authentication type and algorithm used. Because it is a client-generated key pair, it also includes the proof-of-possession of the private key using the <ProofOfPossession> element. The client uses a previously registered key to sign the <Prototype> element and represents the signature under the <KeyBindingAuth> element. The <Respond> element specifies the actual return values via the <KeyName>, <KeyValue>, and its <RetrievalMethod> elements. In the case of a service-generated key pair, the request does not contain the public-key information and the XKMS trust service provider responds to the requests with the private key along with the binding information.

Now, let's take a look at Example 6-33, the response obtained from the XKMS trust service provider after it registered the client-generated key-pair.

Example 6-33. X-KRSS registration response from an XKMS trust service

<RegisterResult>      <Result>Success</Result>      <Answer>       <Status>Valid</Status>      <KeyID>http://www.cspsecurity.com/myapplication</KeyID>       <ds:KeyInfo>      <ds:RetrievalMethod      URI="http://trustservice.com/?company=csp;CN=web?sl-no='fju24jf'"      Type = http://www.w3.org/2000/09/xmldsig#X509Data"/>       <ds:KeyValue>       <ds:RSAKeyValue>...</ds:RSAKeyValue>        </ds:KeyValue        <ds:KeyName> http://www.cspsecurity.com/myapplication</ds:KeyName>       </ds:KeyInfo>      </Answer> </RegisterResult>

The complete response from the trust service is identified by the <RegisterResult> element. The <Answer> element contains the requested key binding information as the child element <KeyBinding>. The <KeyID> identifies the key registered and <ds:RetrievalMethod> provides the URI location of the key and its type.

X-KRSS Key Revocation Service

The X-KRSS key revocation service defines a protocol that allows revoking previously issued assertions. This protocol is quite similar to the registration services, except that the <Status> element in the request message will be specified Invalid and identify the <KeyID> and <ds:KeyInfo> elements. The revocation response from the service provider will be quite similar to the registration response message, except with the prototype <Status> element specified as Invalid. If the XKMS service provider does not possess the key information, it responds with the <Status> element specified as NotFound.

X-KRSS Key Recovery Service

The Key recovery service defines a protocol for recovery of a private key. When a client forgets or loses its previously registered private key, the key may be recovered by sending a recovery request. The request is quite similar to that of the registration services, except that the <Status> element will be specified Indeterminate, identifying the <KeyName> specified in the <ds:KeyInfo> element. When a recovery is requested, the trust service recovers the private key and the binding with the public key. The response from the XKMS service provider will be quite similar to the revocation response message. If more time to process the response is required, the XKMS trust service responds with a <ResultCode> as Pending.

If the XKMS service provider does not possess the key information, it responds with NotFound in the <Status> element.

X-KRSS Key Reissue Service

The key reissue service defines a protocol to reissue the previously issued assertions. It returns a similar response by sending a registration response with newer issuing credentials from the underlying PKI of the XKMS trust service.

X-BULK

X-BULK defines a single batch element that can contain multiple registration requests, responses, and status requests. The responding XKMS service processes the entire batch and returns a single response after processing. Without X-BULK support, XKMS would be limited to a single key registration and validation at a time. X-BULK operations are primarily meant for issuing multiple certificates to support deploying smart phone devices, smart cards, modems, and so forth.

X-BULK defines batch elements, such as <BulkRegister>, <BulkResponse>, <BulkStatusRequest>, and <BulkStatusResponse>, representing registration requests and responses, and status requests and responses. Each of these batch elements contains request or response messages that include requests or responses that are independently referenced. Example 6-34 is an X-BULK request made by a client application for running a bulk registration of certificates.

Example 6-34. X-BULK request for running volume registration of certificates

<BulkRegister xmlns="http://www.w3.org/2002/03/xkms-xbulk">      <SignedPart >           <BatchHeader>                <BatchID>mybatch-0</BatchID>                <BatchTime>...</BatchTime>                <NumberOfRequests>2</NumberOfRequests>           </BatchHeader>           <xkms:Respond>                <string xmlns="">X509Cert</string>           </xkms:Respond>           <Requests number="3">                <Request>                     <xkms:KeyID>                        mailto:admin@coresecuritypatterns.com                     </xkms:KeyID>                     <dsig:KeyInfo>                          <dsig:X509Data>                               <dsig:X509SubjectName>                                    CN=FirstName LastName                               </dsig:X509SubjectName>                          </dsig:X509Data>                          <dsig:KeyValue>                               <dsig:RSAKeyValue>                                    ...                               </dsig:RSAKeyValue>                          </dsig:KeyValue>                     </dsig:KeyInfo>                     <ClientInfo>                          <userID                          xmlns="urn:csp">                               12345                          </userID>                     </ClientInfo>                </Request>                <Request>...</Request>             <Request>...</Request>           </Requests>      </SignedPart>      <dsig:Signature>...</dsig:Signature> </BulkRegister>

In Example 6-34, the <BulkRegister> element represents a bulk request message that contains the batch ID, the type of response from the XKMS service, the sequence of the requests, and the signature used to sign the bulk request. The <BatchHeader> child element consists of general batch-related information, such as the batch ID, batch creation date, and the number of requests included in the batch. The <Request> element carries the individual requests, including the <KeyID> and <ds:KeyInfo> elements for those requests. The <ClientInfo> element specifies client-specific information about each request that can be used by the trust services provider for bookkeeping. The <dsig:Signature> element specifies the digital signature used to sign the X-BULK message.

Example 6-35 is an example X-BULK response message received from the XKMS service provider after processing the bulk request containing three individual requests.

Example 6-35. X-BULK response after running volume registration of certificates

<BulkRegisterResult xmlns="http://www.w3.org/2002/03/xkms-xbulk">     <SignedPart >           <BatchHeader>                <BatchID>mybatch-0</BatchID>                ...                <NumberOfRequests>3</NumberOfRequests>           </BatchHeader>           <RegisterResults number="2">                <xkms:RegisterResult>                     <xkms:Result>                          Success                     </xkms:Result>                     <xkms:Answer>                          <xkms:Status>                               Valid                          </xkms:Status>                          <xkms:KeyID>...</xkms:KeyID>                          <dsig:KeyInfo>                               ...                          </dsig:KeyInfo>                     </xkms:Answer>                </xkms:RegisterResult>                <xkms:RegisterResult>                     ...                </xkms:RegisterResult>                <xkms:RegisterResult>                     ...                </xkms:RegisterResult>           </RegisterResults>      </SignedPart>      <dsig:Signature>...</dsig:Signature> </BulkRegisterResult>

In Example 6-35, the <BulkRegisterResult> element represents the bulk response containing information such as the batch ID, the number of results included, the actual results to the registration requests, and the signature used to sign the given bulk response. The <BatchID> element identifies the relationship between the batch elements of the bulk request and bulk response. The <RegisterResults> element contains the individual <xkms:RegisterResult> elements, which hold the registration details of the individual requests.