XML Key Management Specification Bulk Operation (X-BULK)

W3C Working Draft 16th April 2002

This version:: http://www.w3.org/2001/XKMS/Drafts/xbulk-20020422.html; $Revision: 1.5 $ on $Date: 2002/02/07 13:00:31 $ GMT
Latest version:: http://www.w3.org/2001/XKMS/Drafts/xbulk.html
Previous version:: http://www.w3.org/2001/XKMS/Drafts/xbulk-20020117.html
Editor:: Merlin Hughes, Baltimore Technologies, merlin@baltimore.ie
Authors:: missing

Abstract

This document extends the XML Key Management Specification [XKMS] protocol to encompass the bulk registration operations necessary for 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.

This is the first draft of the "XML Key Management Specification Bulk Operation (X-BULK)" specification from theW3C XML Key Management Working Group(Activity Statement). This version attempts to capture the consensus resulting from the 1 March 2001 face-to-face meeting and subsequent discussion on thelist. However, it does contain points which are still under discussion or not well specified.

The Working Group will try touse a new namespacewhen changes in its syntax or processing are substantive. However, this namespace might be reused (prior to reaching Candidate Recommendation) by subsequent drafts in such a way as to cause instances using the namespace to become invalid or to change in meaning or affect the operation of existing software. Requests for a more stringent level of namespace stability should be made to the Working Group.

Publication of this document does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a "work in progress." Please send comments to the editor and cc: the listwww-xkms@w3.org(archives).

Patent disclosures relevant to this specification may be found on the Working Group'spatent disclosure pagein conformance with W3C.

A list of current W3C working drafts can be found athttp://www.w3.org/TR/.

Introduction
X-BULK messages
Schema definition
WSDL
References
Acknowledgements (Informative)
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 issuance cases and are proposing that an X-BULK specification, built on the basis of 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 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 at the level of the batch, not 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 will only address bulk registration; it will not seek to address all the operations provided by X-KRSS, such as bulk revocation.

X-BULK does however reuse element definitions from the current X-KRSS specification.

Separating bulk from one-by-one registration 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 register 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

Prefix	Specification	Schema
	XML Schema	http://www.w3.org/2001/XMLSchema
ds	XML Signature	http://www.w3.org/2000/09/xmldsig#
xkms	XKMS	http://www.w3.org/2002/03/xkms#
xbulk	X-BULK	http://www.w3.org/2002/04/xbulk#

These namespaces are declared in the XKMS schema as follows:

Schema Definition:

<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/04/xbulk#"
      xmlns="http://www.w3.org/2001/XMLSchema" 
      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/04/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/2002/03/xkms#"
      schemaLocation="xkms-schema.xsd"/>
   <annotation>
      <documentation xml:lang="en">
              XML Schema for X-BULK draft 2  16th April 2002
      </documentation>
   </annotation>

1.3 Bulk Operations Service Specification

X-BULK defines a batch element that can contain registration requests, responses and status requests. 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 batches MUST be authenticated; that is, the originator of a batch must be able to protect the batch. Implementations MUST support the RSA algorithm for digitally signing batches. Implementations MUST be capable of using the XKMS Register operation for the registration of the keys used to authenticate batches.

Implementations MUST include a ds:X509Data element in the Signature, which is used together with the BatchID to ensure batch uniqueness.

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

Each batch has an information element that identifies the batch (and can contain additional unprocessed information).

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.

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

2.1 The abstract request/response types

2.1.1 The `BulkRequestAbstractType` type

The BulkRequestAbstractType type extends the XKMS abstract request type to include generic batch information:

Schema Definition:

  <complexType name="BulkRequestAbstractType" abstract="true">
    <complexContent>
      <extension base="xkms:RequestAbstractType">
        <sequence>
          <element ref="xbulk:BatchInfo"/>
        </sequence>
      </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 to include generic batch information:

Schema Definition:

  <complexType name="BulkResultAbstractType" abstract="true">
    <complexContent>
      <extension base="xkms:ResultAbstractType">
        <sequence>
          <element ref="xbulk:BatchInfo"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

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

2.1.3 The `BatchInfo` element

The BatchInfo element is common to all the mesages in this document; it contains the following information:

A batch ID
A batch creation date
The number of requests in the batch
Additional processing information for the responder.

BatchID combined with the originating party X509Data (from the Signature) MUST be unique at a given moment in time.

Schema Definition:

  <complexType name="BatchInfoType">
    <choice minOccurs="0" maxOccurs="unbounded">
      <sequence>
        <element name="BatchID" type="string"/>
        <element name="BatchTime" type="dateTime"/>
        <element name="NumberOfRequests" type="positiveInteger"/>
        <element ref="xkms:ProcessInfo" minOccurs="0"/>
      </sequence>
    </choice>
  </complexType>

  <element name="BatchInfo" type="xbulk:BatchInfoType"/>

2.2 Bulk registration

The following messages comprise the bulk registration process:

2.2.1 The `BulkRegisterRequest` message

The BulkRegisterRequest message is an XML element that consists of a BatchInfo, a response profile, a sequence of requests and a Signature over the entire message.

Schema Definition:

  <complexType name="BulkRegisterRequestType">
    <complexContent>
      <extension base="xbulk:BulkRequestAbstractType">
        <sequence>
          <element ref="xbulk:BulkPrototype" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkRegisterRequest" type="xbulk:BulkRegisterRequestType"/>

Authentication is realized through the digital signature inherited from MessageAbstractType.
Response profiling is realized through the RespondWith element inherited from RequestAbstractType. The full set of allowed RespondWith values is defined in [XKMS]. Implementations MUST support Pending.
Batch completion can be notified via the PendingRequest element inherited from RequestAbstractType.
Data associated with each individual registration are encapsulated in the BulkPrototype element.

2.2.2 The `BulkPrototype` element

The BulkPrototype element associates a ClientInfo element, which may contain per-registration client-side book keeping information, with an XKMS Prototype element.

Schema Definition:

  <complexType name="BulkPrototypeType">
    <sequence>
      <element ref="xkms:Prototype"/>
      <element ref="xbulk:ClientInfo" minOccurs="0"/>
    </sequence>
  </complexType>

  <element name="BulkPrototype" type="xbulk:BulkPrototypeType"/>

The following types of ds:KeyInfo within a xkms:Prototype MUST be supported:

A PKCS10 request
A ds:X509SubjectName and key data (in which case the key data can either be a ds:KeyValue or a PKCS1 public key)
A ds:X509SubjectName without key data (server generated keys)

In addition, the following KeyInfo types from [XMLDSIG] SHOULD be supported: ds:KeyName, ds:KeyValue, ds:RetrievalMethod, and ds:X509Data.

2.2.3 The `ClientInfo` element

ClientInfo, if present, MUST be ignored and treated as opaque data by the responder. This element must be returned in the corresponding BulkKeyBinding element. This can be used by the client for bookkeeping.

Schema Definition:

  <complexType name="ClientInfoType">
    <sequence maxOccurs="unbounded">
      <any namespace="##other"/>
    </sequence>
  </complexType>

  <element name="ClientInfo" type="xbulk:ClientInfoType"/>

2.2.4 The `BulkRegisterResult` message

The BulkRegisterResult contains the batch information, and one (and only one) BulkKeyBinding for each and every BulkPrototype element in the corresponding BulkRegisterRequest.

Schema Definition:

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

  <element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/>

2.2.5 The `BulkKeyBinding` element

The BulkKeyBinding element associates a ClientInfo element and optional private key with the sequence of XKMS key bindings that may result from an individual registration request.

Schema Definition:

  <complexType name="BulkKeyBindingType">
    <sequence>
      <element ref="xkms:Prototype" maxOccurs="unbounded"/>
      <element ref="xkms:Private" minOccurs="0"/>
      <element ref="xbulk:ClientInfo" minOccurs="0"/>
    </sequence>
  </complexType>

  <element name="BulkKeyBinding" type="xbulk:BulkKeyBindingType"/>

2.2.6 `BulkRegisterRequest` example

An example BulkRegisterRequest message follows:

<xbulk:BulkRegisterRequest
    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/04/xbulk#"
    MajorVersion="2"
    MinorVersion="0"
    Service="http://example.org/xbulk"
    RequestID="bulk-register-0">
  <ds:Signature> ... URI="#bulk-register-0" ... </ds:Signature>
  <xkms:RespondWith>X509Cert</xkms:RespondWith>
  <xkms:RespondWith>Pending</xkms:RespondWith>
  <xkms:PendingNotification Mechanism="rfc822" Identifier="mailto:1234@example.org" />
  <xbulk:BatchInfo>
    <xbulk:BatchID>batch-0</xbulk:BatchID>
    <xbulk:BatchTime>1999-05-31T13:20:00-05:00</xbulk:BatchTime>
    <xbulk:NumberOfRequests>2</xbulk:NumberOfRequests>
  </xbulk:BatchInfo>
  <xbulk:Prototype>
    <xkms:Prototype>
      <xkms:Status>Valid</xkms:Status>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509SubjectName>CN=Bar Foo</ds:X509SubjectName>
        </ds:X509Data>
        <ds:KeyValue>
          <ds:RSAKeyValue>
            <ds:Modulus>...</ds:Modulus>
            <ds:Exponent>AQAB</ds:Exponent>
          </ds:RSAKeyValue>
        </ds:KeyValue>
      </ds:KeyInfo>
    </xkms:Prototype>
    <ClientInfo>
      <EmployeeID xmlns="http://example.org/emp">6</EmployeeID>
    </ClientInfo>
  </xbulk:Prototype>
  <xbulk:Prototype>
    <xkms:Prototype>
      <xkms:Status>Valid</xkms:Status>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509SubjectName>CN=Baz Foo</ds:X509SubjectName>
        </ds:X509Data>
        <ds:KeyValue>
          <ds:RSAKeyValue>
            <ds:Modulus>...</ds:Modulus>
            <ds:Exponent>AQAB</ds:Exponent>
          </ds:RSAKeyValue>
        </ds:KeyValue>
      </ds:KeyInfo>
    </xkms:Prototype>
    <ClientInfo>
      <EmployeeID xmlns="http://example.org/emp">007</EmployeeID>
    </ClientInfo>
  </xbulk:Prototype>
</xbulk:BulkRegisterRequest>

2.2.7 `BulkRegisterResult` example

A sample response to the first example request:

<xbulk:BulkRegisterResult
    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/04/xbulk#"
    MajorVersion="2"
    MinorVersion="0"
    ResultMajor="Success"
    RequestID="bulk-register-0"
    ResponseID="bulk-register-result-0">
  <ds:Signature> ... URI="#bulk-register-result-0" ... </ds:Signature>
  <xbulk:BatchInfo>
    <xbulk:BatchID>batch-0</xbulk:BatchID>
    <xbulk:BatchTime>1999-05-31T13:20:00-05:00</xbulk:BatchTime>
    <xbulk:NumberOfRequests>2</xbulk:NumberOfRequests>
  </xbulk:BatchInfo>
  <xbulk:KeyBinding>
    <xkms:KeyBinding>
      <xkms:Status>Valid</xkms:Status>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </xkms:KeyBinding>
    <ClientInfo>
      <EmployeeID xmlns="http://example.org/emp">6</EmployeeID>
    </ClientInfo>
  </xbulk:KeyBinding>
  <xbulk:KeyBinding>
    <xkms:KeyBinding>
      <xkms:Status>Valid</xkms:Status>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </xkms:KeyBinding>
    <ClientInfo>
      <EmployeeID xmlns="http://example.org/emp">007</EmployeeID>
    </ClientInfo>
  </xbulk:KeyBinding>
</xbulk:BulkRegisterResult>

2.3 Bulk status check

The following messages comprise the batch status checking process:

2.3.1 The `BulkStatusRequest` message

The BulkStatusRequest message is an XML element that consists of just a BatchInfo and optional Signature.

Schema Definition:

  <complexType name="BulkStatusRequestType">
    <complexContent>
      <extension base="xbulk:BulkRequestAbstractType">
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkStatusRequest" type="xbulk:BulkStatusRequestType"/>

The BulkStatusRequest is a request for the current status of a batch. The batch is identified by its BatchInfo.

Response profiling has no meaning for this message; the inherited RespondWith MUST NOT contain any of the codes corresponding to returned key info types.

2.3.2 The `BulkStatusResult` message

The BulkStatusResult returns the processing status of a previously-submitted batch.

Schema Definition:

  <complexType name="BulkStatusResultType">
    <complexContent>
      <extension base="xbulk:BulkResultAbstractType">
        <sequence>
          <element name="Pending" type="positiveInteger"/>
          <element name="Successful" type="positiveInteger"/>
          <element name="Failed" type="positiveInteger"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/>

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

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

2.3.3 `BulkStatusRequest` example

An example BulkStatusRequest message follows:

<xbulk:BulkStatusRequest
    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/04/xbulk#"
    MajorVersion="2"
    MinorVersion="0"
    Service="http://example.org/xbulk"
    RequestID="bulk-status-0">
  <ds:Signature> ... URI="#bulk-status-0" ... </ds:Signature>
  <xbulk:BatchInfo>
    <xbulk:BatchID>batch-0</xbulk:BatchID>
    <xbulk:BatchTime>1999-05-31T13:20:00-05:00</xbulk:BatchTime>
    <xbulk:NumberOfRequests>2</xbulk:NumberOfRequests>
  </xbulk:BatchInfo>
</xbulk:BulkStatusRequest>

2.3.4 `BulkStatusResult` example

A corresponding BulkStatusResult message follows:

<xbulk:BulkStatusResult
    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/04/xbulk#"
    MajorVersion="2"
    MinorVersion="0"
    Service="http://example.org/xbulk"
    RequestID="bulk-status-0"
    ResponseID="bulk-status-result-0">
  <ds:Signature> ... URI="#bulk-status-result-0" ... </ds:Signature>
  <xbulk:BatchInfo>
    <xbulk:BatchID>batch-0</xbulk:BatchID>
    <xbulk:BatchTime>1999-05-31T13:20:00-05:00</xbulk:BatchTime>
    <xbulk:NumberOfResults>2</xbulk:NumberOfResults>
  </xbulk:BatchInfo>
  <xbulk:Pending>1</xbulk:Pending>
  <xbulk:Successful>1</xbulk:Successful>
  <xbulk:Failed>0</xbulk:Failed>
</xbulk:BulkStatusResult>

2.4 New children of `ds:KeyInfo`

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

2.4.1 The `PKCS1` element

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

Schema Definition:

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

2.4.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/04/xbulk#"
      xmlns="http://www.w3.org/2001/XMLSchema" 
      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/04/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/2002/03/xkms#"
      schemaLocation="xkms-schema.xsd"/>
   <annotation>
      <documentation xml:lang="en">
              XML Schema for X-BULK draft 2  16th April 2002
      </documentation>
   </annotation>

  <!-- abstract types -->

  <complexType name="BulkRequestAbstractType" abstract="true">
    <complexContent>
      <extension base="xkms:RequestAbstractType">
        <sequence>
          <element ref="xbulk:BatchInfo"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="BulkResultAbstractType" abstract="true">
    <complexContent>
      <extension base="xkms:ResultAbstractType">
        <sequence>
          <element ref="xbulk:BatchInfo"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <!-- batch information -->

  <complexType name="BatchInfoType">
    <choice minOccurs="0" maxOccurs="unbounded">
      <sequence>
        <element name="BatchID" type="string"/>
        <element name="BatchTime" type="dateTime"/>
        <element name="NumberOfRequests" type="positiveInteger"/>
        <element ref="xkms:ProcessInfo" minOccurs="0"/>
      </sequence>
    </choice>
  </complexType>

  <element name="BatchInfo" type="xbulk:BatchInfoType"/>

  <!-- bulk registration -->

  <complexType name="BulkRegisterRequestType">
    <complexContent>
      <extension base="xbulk:BulkRequestAbstractType">
        <sequence>
          <element ref="xbulk:BulkPrototype" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkRegisterRequest" type="xbulk:BulkRegisterRequestType"/>

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

  <element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/>

  <complexType name="BulkPrototypeType">
    <sequence>
      <element ref="xkms:Prototype"/>
      <element ref="xbulk:ClientInfo" minOccurs="0"/>
    </sequence>
  </complexType>

  <element name="BulkPrototype" type="xbulk:BulkPrototypeType"/>

  <complexType name="BulkKeyBindingType">
    <sequence>
      <element ref="xkms:Prototype" maxOccurs="unbounded"/>
      <element ref="xkms:Private" minOccurs="0"/>
      <element ref="xbulk:ClientInfo" minOccurs="0"/>
    </sequence>
  </complexType>

  <element name="BulkKeyBinding" type="xbulk:BulkKeyBindingType"/>

  <complexType name="ClientInfoType">
    <sequence maxOccurs="unbounded">
      <any namespace="##other"/>
    </sequence>
  </complexType>

  <element name="ClientInfo" type="xbulk:ClientInfoType"/>

  <!-- batch status check -->

  <complexType name="BulkStatusRequestType">
    <complexContent>
      <extension base="xbulk:BulkRequestAbstractType">
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkStatusRequest" type="xbulk:BulkStatusRequestType"/>

  <complexType name="BulkStatusResultType">
    <complexContent>
      <extension base="xbulk:BulkResultAbstractType">
        <sequence>
          <element name="Pending" type="positiveInteger"/>
          <element name="Successful" type="positiveInteger"/>
          <element name="Failed" type="positiveInteger"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/>

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

Profile inherited elements and attributes
Confirm that we don't need an Authentication element
Encapsulate or extend Prototype?
Support multiple KeyBinding results per registration?
Support partial results (no)
Specify e.g., X.509 DN templates (no)
Support batch Revoke? Reissue? Recover?

XML Key Management Specification Bulk Operation (X-BULK)

W3C Working Draft 16th April 2002

Abstract

Status of this document

Table of Contents

1. Introduction

1.1 Overview

1.2 Namespaces

1.3 Bulk Operations Service Specification

1.4 Editorial and Conformance Conventions

1.5 Structure of this Document

2. X-BULK messages

2.1 The abstract request/response types

2.1.1 The BulkRequestAbstractType type

2.1.2 The BulkResultAbstractType type

2.1.3 The BatchInfo element

2.2 Bulk registration

2.2.1 The BulkRegisterRequest message

2.2.2 The BulkPrototype element

2.2.3 The ClientInfo element

2.2.4 The BulkRegisterResult message

2.2.5 The BulkKeyBinding element

2.2.6 BulkRegisterRequest example

2.2.7 BulkRegisterResult example