XML Key Management Specification Bulk Operation (X-BULK)

Abstract

This document extends the XML Key Management Specification [XKMS] protocol to encompass the bulk operations necessary for aggregate key management operations and interfacing with such systems as smart card management systems.

X-BULK is defined in terms of structures expressed in the XML Schema Language [XML-Schema] and web services description language [WSDL].

Status of this document

This is an editor's copy and has no status at all.

Table of Contents

1. Introduction
   1. Overview
   2. Namespaces
   3. Bulk Operations Service Specification
   4. Editorial and Conformance Conventions
   5. Structure of this Document
2. X-BULK messages
   1. The abstract request/response types
      1. The BulkRequestAbstractType type
      2. The BulkResultAbstractType type
      3. The BulkResultInfoAbstractType type
   2. Bulk locate operation
      1. The BulkLocateRequest message
      2. The BulkLocateResult message
      3. The BulkLocateInfo element
   3. Bulk validate operation
      1. The BulkValidateRequest message
      2. The BulkValidateResult message
      3. The BulkValidateInfo element
   4. Bulk register operation
      1. The BulkRegisterRequest message
      2. The BulkRegisterResult message
      3. The BulkRegisterInfo element
   5. Bulk revoke operation
      1. The BulkRevokeRequest message
      2. The BulkRevokeResult message
      3. The BulkRevokeInfo element
   6. Bulk status check operation
      1. The BulkStatusRequest message
      2. The BulkStatusResult message
   7. New children of ds:KeyInfo
      1. The PKCS1 element
      2. The PKCS10 element
3. Schema definition
4. WSDL
5. References
6. Acknowledgements (Informative)
7. Outstanding issues (Informative)

1. Introduction

XKMS currently addresses one-by-one registration (X-KRSS) and key information and validation services (X-KISS). However, we feel that a standard must also address bulk processing cases and are proposing that an X-BULK specification, built on the basis of X-KISS and X-KRSS be included in scope of the work.

1.1 Overview

The use cases where X-BULK is required include:

• Smart card factories for enterprise, wireless and cable-modem applications
• Device factories in general (e.g. TCPA-like TPM modules)
• To handle functionality analogous to separated RAs and CAs from the X.509 world
• Key retrieval during encryption for multiple recipients.
• Mass credential update during corporate reorganization.

Key differences between X-KRSS and X-BULK include:

• X-BULK is required to correlate batches of requests and responses.
• X-KRSS doesn't support some legacy key registration formats (e.g. PKCS#10), which are important for existing hardware modules.
• Authentication and response profiling should be possible at the level of the batch, not just the individual request.
• Batch status is not the same as key status.
• X-BULK addresses interfacing with card administration and deployment back-end servers (a.k.a. card management systems).

X-BULK does however attempt to reuse as many structures and features as possible from the current XKMS specification.

Separating bulk from one-by-one processing has the benefit that the separately defined messages required are simpler than if a single message format handling both one-by-one and bulk cases were to be defined. It is also better not to burden a client for one-by-one operation with the additional complexity required in batch operation.

Demand for this functionality is shown by the emergence of a number of proprietary solutions in this space.

Design criteria include:

• Consistency with and reuse of [XKMS]
• To handle batches of key management requests and responses
• To handle legacy cryptographic formats prevalent in current hardware environments, in particular, [PKCS10] and [PKCS1] as well as KeyInfo from [XMLDSIG]
• To handle both client and server side key generation
• Simplicity and flexibility

1.2 Namespaces

For clarity, some examples of XML are not complete documents and namespace [XML-Names] declarations may be omitted from XML fragments. In this document, certain namespace prefixes represent certain namespaces as follows

These namespaces are declared in the X-BULK schema as follows:

Schema Definition:

<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/08/xbulk#" 
      xmlns="http://www.w3.org/2001/XMLSchema" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xkms="http://www.w3.org/2002/03/xkms#"
      xmlns:xbulk="http://www.w3.org/2002/08/xbulk#" elementFormDefault="qualified" 
      attributeFormDefault="unqualified">

   <import namespace="http://www.w3.org/2000/09/xmldsig#" 
         schemaLocation="xmldsig-core-schema.xsd"/>
   <import namespace="http://www.w3.org/2001/04/xmlenc#" 
         schemaLocation="xenc-schema.xsd"/>
   <import namespace="http://www.w3.org/2002/03/xkms#" 
         schemaLocation="xkms-schema.xsd"/>

   <annotation>
      <documentation xml:lang="en">
         XML Schema for XBULK draft 22nd August 2002
      </documentation>
   </annotation>

1.3 Bulk Operations Service Specification

X-BULK defines request and result messages that are bulk equivalents of the protocol messages defined in X-KISS and X-KRSS, along with additional messages for querying the status of a bulk request. The basic idea is that a single batch can contain a number of independently referencable requests or responses. Batches are produced both from the requestor and responder. A responder will process an entire batch and produce a single batch of responses after processing.

All bulk requests MUST be authenticated; that is, the originator of a batch must protect the batch with a digital signature. In particular, there is no proof of possession or authorization on a per-key binding level; instead, the entire bulk operation is authenticated by the originator. Implementations MUST be capable of using the XKMS Register operation for the registration of the keys used to authenticate batches.

The basic mode of operation is that a batch of requests is submitted. The responder processes the batch and produces a response batch that contains one response for each request in the batch. Other, more flexible modes of operation may be defined later (e.g. allowing responses to be spread over multiple batches). This mode of "full batch processing" is sufficient for most use cases and is considerably simpler than supporting "selective batch processing."

Batches are identified using ID attributes and optional opaque client data that is carried unaltered by the responder.

In order to allow the requestor to track the progress of batch processing implementations MAY support status requests. A status request is a request to determine the status of processing of the referenced batch. The response gives a simple indication of the numbers of requests from the batch that are in the various possible states (processed, failed, etc.).

A batch response contains one response for each request, not necessarily in the same order as in the request batch. That is, requestors MUST be able to handle responses that are not sorted in any particular way. Correlativity between individual requests and responses can be identified either based in information within the key binding, or through the use of ID attributes on the requests, which are automatically included in the responses.

In many use cases, the requestor requires "additional information" to be "carried around" with a batch or request, but which is not intended for processing by the responder.

Responders MAY also add more additional information to the specific responses. Requestors MUST be able to handle such additional information.

The basic request and response structures are as in [XKMS] and can support the same level of functionality (registration of new keys, local/central key generation, revocation, location, etc.).

1.4 Editorial and Conformance Conventions

This specification uses XML Schemas [XML-Schema] to describe the content model.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [Keywords]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-Names] is described as "REQUIRED."

1.5 Structure of this Document

The remainder of this document describes the X-BULK messages; first the generic message types; then the messages and elements associated with bulk registration, along with examples; and then the messages associated with bulk status checking, along with examples. Finally the complete schema for X-BULK and the [WSDL] definition are presented.

2. X-BULK messages

X-BULK messages reuse the standard XKMS abstract request/response framework.

• Opaque client-specific data can be associated with a particular batch by including them in the inherited OpaqueClientData message element. This will be stored by the X-BULK responder, and returned to the client when processing is complete.
• Opaque client-specific data can be associated with individual requests in a batch by including them in the global inherited OpaqueClientData message element and using a reference to the Id attribute of the associated request.
• Vendor-specific data can be included within a request through the KeyBinding and KeyInfo extensibility mechanisms.

2.1 The abstract request/response types

2.1.1 The BulkRequestAbstractType type

The BulkRequestAbstractType type extends the XKMS abstract request type to include information about the number of requests in the batch:

Schema Definition:

   <complexType name="BulkRequestAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <attribute name="NumberOfRequests" type="positiveInteger"/>
         </extension>
      </complexContent>
   </complexType>

Processing of the inherited attributes and elements is the same as specified in XKMS.

2.1.2 The BulkResultAbstractType type

The BulkResultAbstractType type extends the XKMS abstract result type but currently includes no additional information:

Schema Definition:

   <complexType name="BulkResultAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:RequestAbstractType"/>
      </complexContent>
   </complexType>

Processing of the inherited attributes and elements is the same as specified in XKMS.

2.1.3 The BulkResultInfoAbstractType type

The BulkResultInfoAbstractType type is used to encapsulate the response to an individual request within a batch. This includes a copy of the Id attribute from the original request key binding, to allow correlation between requests and responses within the batch.

Schema Definition:

   <complexType name="BulkResultInfoAbstractType" abstract="true">
      <attribute name="OriginalKeyBindingId" type="anyURI" use="optional"/>
   </complexType>

2.2 Bulk locate operation

The following messages comprise the bulk location process:

2.2.1 The BulkLocateRequest message

The BulkLocateRequest message is an XML element that consists of a sequence of QueryKeyBinding elements providing information on each desired locate operation.

Schema Definition:

   <element name="BulkLocateRequest" type="xbulk:BulkLocateRequestType"/>
   <complexType name="BulkLocateRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.2.2 The BulkLocateResult message

The BulkLocateResult message is an XML element that consists of a sequence of BulkLocateInfo elements, providing an answer to each of the original requests.

Schema Definition:

   <element name="BulkLocateResult" type="xbulk:BulkLocateResultType"/>
   <complexType name="BulkLocateResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkLocateInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.2.2 The BulkLocateInfo element

The BulkLocateInfo element contains a sequence of zero or more KeyBinding elements, providing the result of a single locate request. The inherited OriginalKeyBindingId attribute allows correlation with the original request.

Schema Definition:

   <element name="BulkLocateInfo" type="xbulk:BulkLocateInfoType"/>
   <complexType name="BulkLocateInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.3 Bulk validate operation

The following messages comprise the bulk validation process:

2.3.1 The BulkValidateRequest message

The BulkValidateRequest message is an XML element that consists of a sequence of QueryKeyBinding elements providing information on each desired validate operation.

Schema Definition:

   <element name="BulkValidateRequest" type="xbulk:BulkValidateRequestType"/>
   <complexType name="BulkValidateRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.3.2 The BulkValidateResult message

The BulkValidateResult message is an XML element that consists of a sequence of BulkValidateInfo elements, providing an answer to each of the original requests.

Schema Definition:

   <element name="BulkValidateResult" type="xbulk:BulkValidateResultType"/>
   <complexType name="BulkValidateResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkValidateInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.3.2 The BulkValidateInfo element

The BulkValidateInfo element contains a sequence of zero or more KeyBinding elements, providing the result of a single validate request. The inherited OriginalKeyBindingId attribute allows correlation with the original request.

Schema Definition:

   <element name="BulkValidateInfo" type="xbulk:BulkValidateInfoType"/>
   <complexType name="BulkValidateInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.4 Bulk register operation

The following messages comprise the bulk registration process:

2.4.1 The BulkRegisterRequest message

The BulkRegisterRequest message is an XML element that consists of a sequence of PrototypeKeyBinding elements providing information on each desired register operation. The entire bulk registration operation is authenticated through an Authentication element. No per-request proof of possession is required for client-generated keys.

Schema Definition:

   <element name="BulkRegisterRequest" type="xbulk:BulkRegisterRequestType"/>
   <complexType name="BulkRegisterRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:PrototypeKeyBinding" maxOccurs="unbounded"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.4.2 The BulkRegisterResult message

The BulkRegisterResult message is an XML element that consists of a sequence of BulkRegisterInfo elements, providing an answer to each of the original requests.

Schema Definition:

   <element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/>
   <complexType name="BulkRegisterResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkRegisterInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.4.2 The BulkRegisterInfo element

The BulkRegisterInfo element contains a sequence of zero or more KeyBinding elements, providing the result of a single register request, and optionally the associated server-generated private key. The inherited OriginalKeyBindingId attribute allows correlation with the original request.

Schema Definition:

   <element name="BulkRegisterInfo" type="xbulk:BulkRegisterInfoType"/>
   <complexType name="BulkRegisterInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.5 Bulk revoke operation

The following messages comprise the bulk revocation process:

2.5.1 The BulkRevokeRequest message

The BulkRevokeRequest message is an XML element that consists of a sequence of KeyBinding elements providing information on each desired revoke operation. The entire bulk revocation operation is authenticated through an Authentication element.

Schema Definition:

   <element name="BulkRevokeRequest" type="xbulk:BulkRevokeRequestType"/>
   <complexType name="BulkRevokeRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" maxOccurs="unbounded"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.5.2 The BulkRevokeResult message

The BulkRevokeResult message is an XML element that consists of a sequence of BulkRevokeInfo elements, providing an answer to each of the original requests.

Schema Definition:

   <element name="BulkRevokeResult" type="xbulk:BulkRevokeResultType"/>
   <complexType name="BulkRevokeResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkRevokeInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.5.2 The BulkRevokeInfo element

The BulkRevokeInfo element contains a sequence of zero or more KeyBinding elements, providing the result of a single revoke request. The inherited OriginalKeyBindingId attribute allows correlation with the original request.

Schema Definition:

   <element name="BulkRevokeInfo" type="xbulk:BulkRevokeInfoType"/>
   <complexType name="BulkRevokeInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

2.6 Bulk status check operation

The following messages comprise the batch status checking process:

2.6.1 The BulkStatusRequest message

The BulkStatusRequest message is an XML element that contains a ResponseId attribute to identify the batch whose status is in question.

Schema Definition:

   <element name="BulkStatusRequest" type="xbulk:BulkStatusRequestType"/>
   <complexType name="BulkStatusRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <!-- Authentication? -->
            <attribute name="ResponseId" type="anyURI" use="optional"/>
         </extension>
      </complexContent>
   </complexType>

2.6.2 The BulkStatusResult message

The BulkStatusResult message is an XML element that returns the processing status of a previously-submitted batch.

Schema Definition:

   <element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/>
   <complexType name="BulkStatusResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element name="Pending" type="positiveInteger"/>
               <element name="Successful" type="positiveInteger"/>
               <element name="Failed" type="positiveInteger"/>
            </sequence>
            <attribute name="Complete" type="boolean"/>
         </extension>
      </complexContent>
   </complexType>

The status is presented simply in the form of the following data:

• The number of requests pending
• The number that have completed successfully
• The number that have failed
• A flag that indicates whether batch processing is complete

One application might be to use a XML style sheet to present this information to the customer over a web page.

2.7 New children of ds:KeyInfo

The following new children of ds:KeyInfo are defined, for integration with legacy systems:

2.7.1 The PKCS1 element

The PKCS1 element contains a DER-encoded [PKCS1] public key.

Schema Definition:

  <element name="PKCS1" type="binary"/>

2.7.2 The PKCS10 element

The PKCS10 element contains a DER-encoded [PKCS10] public key.

Schema Definition:

  <element name="PKCS10" type="binary"/>

3. Schema definition

The complete schema definition is as follows:

Schema Definition:

<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/08/xbulk#" 
      xmlns="http://www.w3.org/2001/XMLSchema" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xkms="http://www.w3.org/2002/03/xkms#"
      xmlns:xbulk="http://www.w3.org/2002/08/xbulk#" elementFormDefault="qualified" 
      attributeFormDefault="unqualified">

   <import namespace="http://www.w3.org/2000/09/xmldsig#" 
         schemaLocation="xmldsig-core-schema.xsd"/>
   <import namespace="http://www.w3.org/2001/04/xmlenc#" 
         schemaLocation="xenc-schema.xsd"/>
   <import namespace="http://www.w3.org/2002/03/xkms#" 
         schemaLocation="xkms-schema.xsd"/>

   <annotation>
      <documentation xml:lang="en">
         XML Schema for XBULK draft 22nd August 2002
      </documentation>
   </annotation>

   <!-- abstract types -->

   <complexType name="BulkRequestAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <attribute name="NumberOfRequests" type="positiveInteger"/>
         </extension>
      </complexContent>
   </complexType>

   <complexType name="BulkResultAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:RequestAbstractType"/>
      </complexContent>
   </complexType>

   <complexType name="BulkResultInfoAbstractType" abstract="true">
      <attribute name="OriginalKeyBindingId" type="anyURI" use="optional"/>
   </complexType>

   <!-- bulk locate -->

   <element name="BulkLocateRequest" type="xbulk:BulkLocateRequestType"/>
   <complexType name="BulkLocateRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkLocateResult" type="xbulk:BulkLocateResultType"/>
   <complexType name="BulkLocateResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkLocateInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkLocateInfo" type="xbulk:BulkLocateInfoType"/>
   <complexType name="BulkLocateInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <!-- bulk validate -->

   <element name="BulkValidateRequest" type="xbulk:BulkValidateRequestType"/>
   <complexType name="BulkValidateRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkValidateResult" type="xbulk:BulkValidateResultType"/>
   <complexType name="BulkValidateResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkValidateInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkValidateInfo" type="xbulk:BulkValidateInfoType"/>
   <complexType name="BulkValidateInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <!-- bulk register -->

   <element name="BulkRegisterRequest" type="xbulk:BulkRegisterRequestType"/>
   <complexType name="BulkRegisterRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:PrototypeKeyBinding" maxOccurs="unbounded"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/>
   <complexType name="BulkRegisterResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkRegisterInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkRegisterInfo" type="xbulk:BulkRegisterInfoType"/>
   <complexType name="BulkRegisterInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <!-- bulk revoke -->

   <element name="BulkRevokeRequest" type="xbulk:BulkRevokeRequestType"/>
   <complexType name="BulkRevokeRequestType">
      <complexContent>
         <extension base="xbulk:BulkRequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" maxOccurs="unbounded"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkRevokeResult" type="xbulk:BulkRevokeResultType"/>
   <complexType name="BulkRevokeResultType">
      <complexContent>
         <extension base="xbulk:BulkResultAbstractType">
            <sequence>
               <element ref="xbulk:BulkRevokeInfo" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkRevokeInfo" type="xbulk:BulkRevokeInfoType"/>
   <complexType name="BulkRevokeInfoType">
      <complexContent>
         <extension base="xbulk:BulkResultInfoAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>

   <!-- No Bulk Reissue / Recover yet.. just reuse xkms:Pending? -->

   <!-- bulk status -->

   <element name="BulkStatusRequest" type="xbulk:BulkStatusRequestType"/>
   <complexType name="BulkStatusRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <!-- Authentication? -->
            <attribute name="ResponseId" type="anyURI" use="optional"/>
         </extension>
      </complexContent>
   </complexType>

   <element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/>
   <complexType name="BulkStatusResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element name="Pending" type="positiveInteger"/>
               <element name="Successful" type="positiveInteger"/>
               <element name="Failed" type="positiveInteger"/>
            </sequence>
            <attribute name="Complete" type="boolean"/>
         </extension>
      </complexContent>
   </complexType>

   <!-- key info types -->

   <element name="PKCS1" type="binary"/>

   <element name="PKCS10" type="binary"/>

</schema>

4. WSDL

The WSDL is as follows:

WSDL Definition:

<!-- to follow from a more stable schema -->

5. References

Keywords

RFC 2119. Key words for use in RFCs to Indicate Requirement Levels. Best Current Practice. S. Bradner. March 1997.

http://www.ietf.org/rfc/rfc2119.txt

PKCS1

PKCS #1. RSA Cryptography Specifications Version 2.0. B. Kaliski and J. Staddon. September 1998.

http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/

Also RFC 2437.

PKCS10

PKCS #10. Certification Request Syntax Standard Version 1.7. RSA Laboratories. 26 May 2000.

http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/

XMLDSIG

XML-Signature Syntax and Processing. IETF Draft/W3C Proposed Recommendation. D. Eastlake, J. Reagle, and D. Solo. 31 August 2001.

http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/

XKMS

XML Key Management Specification (XKMS). W3C Working Draft. TBS. 21 November 2001.

http://www.w3.org/2001/XKMS/Drafts/xkms.html

XML-Names

Namespaces in XML. W3C Recommendation. T. Bray, D. Hollander, and A. Layman. January 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114/

XML-Schema

XML Schema Part 1: Structures. W3C Working Draft. H. S. Thompson, D. Beech, M. Maloney and N. Mendelsohn. 22 September 2000.

http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/, latest draft at http://www.w3.org/TR/xmlschema-1/

XML Schema Part 2: Datatypes. W3C Working Draft. P. V. Biron and A. Malhotra. 22 September 2000.

http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/, latest draft at http://www.w3.org/TR/xmlschema-2/

WSDL

Web Services Description Language (WSDL) 1.0. E. Christensen, F. Curbera, G. Meredith, S. Weerawarana. 25 September 2000.

http://msdn.microsoft.com/xml/general/wsdl.asp

6. Acknowledgements (Informative)

The following people provided valuable feedback that improved the quality of this specification:

• Patrick George, Gemplus
• Pierre Heuze, Cardbase
• Jean-Claude Perrin, Schlumberger
• François Rajchenbach, Oberthur Card Systems
• James Webster, Cards etc

7. Outstanding issues (Informative)

1. Locate/validate?
2. Profiling?
3. Confirm the use of signatures/authentication
4. Support partial results (no)
5. Specify e.g., X.509 DN templates (no)
6. Support batch Reissue? Recover?