Management Operation
Resume:
.
.
.
. For further information, contact:
.
. *****@********.*********.***
.
.
.
XML Key Management Specification Bulk
Operation (X-BULK)
. . . . . . . . . .
Baltimore Technologies
Gemplus
Oberthur Card Systems
Schlumberger
Draft Version 1.1 draft 4: July 6 2001
Version 1.1 draft 4 July 6 2001 Page 1
Page 2 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
Table Of Contents
Executive Summary 3
1 Introduction 3
1.1 Overview 3
1.2 Namepaces 4
1.3 Bulk Operations Service Specification 4
1.4 Structure of this document 5
2 BatchHeader 6
3 BulkRegister 6
3.1 ResponseProfile - 6
3.2 Requests 6
3.3 Example 7
4 BulkStatus 8
4.1 BulkStatusRequest 8
4.2 Example 8
4.3 BulkStatus 9
4.4 Example 9
5 BulkRegisterResult 9
5.1 RegisterResults 10
5.2 Example 1 10
5.3 Schema 12
6 WSDL 14
7 Authors 17
Appendix A References 18
Appendix B Legal Notices 18
2
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 3
Executive Summary
This document extends the [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 and
web services description language [WSDL].
1 Introduction
1.1 Overview
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.
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 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
3
Page 4 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
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, [PKCS#10] and [PKCS#1] as well as KeyInfo from
[XMLDSIG]
To handle both client and server side key generation
Simplicity and flexibility
1.2 Namepaces
For clarity, some examples of XML are not complete documents and namespace
declarations may be omitted from XML fragments. In this document, certain namespace
prefixes represent certain namespaces. References to XML schema defined herein use the
prefix xbulk and are in the namespace:
xmlns:xbulk=http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-07-04.xsd
This specification uses the elements already defined in the XKMS and XML Signature
namespaces. The XKMS namespace is represented by the prefix s0 and is declared as
xmlns:s0=http://www.xmltrustcenter.org/xml/schema/2000-11-12-XKMS.sdl.
The XML Signature namespace is represented by the prefix ds and is declared as
xmlns:ds=http://www.w3.org/2000/09/xmldsig#. The XML Signature schema is defined
in http://www.w3.org/2000/09/xmldsig, and the element (and all of its
contents) are found at http://www.w3.org/2000/09/xmldsig#sec-KeyInfo. The
corresponding XML Schema definition can be found in xmldsig-core-schema.xsd.
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.
4
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 5
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 an X509Data element in the Signature, which is used
together with the BatchID to ensure batch uniqueness. All such Signature elements
MUST be enveloped signatures, that is, they MUST authenticate the entire X-BULK
message.
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 a header 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, revocation,
etc.).
1.4 Structure of this document
The remainder of this document describes the X-BULK messages, first the "outside"
elements, then the request specifics, the status messages and finally the response
elements. Finally the complete schema for X-BULK and the WSDL definition are
presented.
5
Page 6 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
2 BatchHeader
The header is common to all the elements in this document; it will optionally contain the
following information:
A Batch ID
A Batch Creation Date
ProcessInfo contains 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.
Things like customer name, that are not actually required for the batch to be processed,
MAY be included as .
123422 May 2001ACME, Inc.
3 BulkRegister
The is an XML element that will consist of a, a response
profile, a sequence of requests and over the header and requests.
3.1 ResponseProfile -
The format of the response to be sent for each request that does not contain an individual
element. The can, for example, indicate that the requests are for:
X509Cert (an X.509 certificate)
RetrievalMethod (Certificate URLs (LDAP or HTTP))
The full set of allowed values is defined in [XKMS]. Implementations MUST
support: KeyName, KeyValue, X509Cert, X509Chain, RetrievalMethod and Private.
3.2 Requests
consists of an unbounded number of elements. The number of
elements in a MUST be an attribute to . A request
MUST also contain the following:
6
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 7
A, which must be unique within the batch (this can anything; examples
include a smart card serial number, a MAC Address (cable modem), ICCID (used
by S/WIM cards) or even simply 1,2,3 ).
A may also contain,, and elements., if present, MUST be ignored and treated as opaque data by the Responder.
This element must be returned in the corresponding element. This can
be used by the client for bookkeeping.
3.2.1 KeyInfo
The MUST contain a PKCS#10 request, or an X509SubjectName and key
data (in which case the key data can either be a or a PKCS#1 public key),
or an without key data (server generated keys).
In addition, the following KeyInfo types from [XMLDSIG] SHOULD be supported:
KeyName, KeyValue, RetrievalMethod, and X509Data.
3.3 Example
123422 May 2001ACME, Inc.RetrievalMethod1
cn=Niall,o=Baltimore,c=IE
MMAsDASFDAsfBarQW4SDGjSDfbgwEJRH=barhello2MMAsDASFDAsfBarQW4SDGjSDfbgwEJRH=
7
Page 8 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
bazgoodbye
...
...
4 BulkStatus
4.1 BulkStatusRequest
The is a request for the current status of a batch. The batch is
identified by its header. The element consists of a and .
The MUST be exactly the same as in the header of the corresponding
element.
4.2 Example
123422 May 2001ACME, Inc.
...
...
8
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 9
4.3 BulkStatus
The is a very simple element that contains the and the
of a batch. The MUST be exactly the same as the header in the
element. This will contain the following:
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.
4.4 Example
123422 May 2001ACME, Inc.8561422
...
...
5 BulkRegisterResult
The contains the header and a certificate response for each request
that was in the batch. The element contains a,, and
.
9
Page 10 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
5.1 RegisterResults
The element contains one (and only one) for each
and every element in the corresponding . The number of
elements MUST be an attribute to .
is defined in [XKMS]; its contents are dictated by the
elements in the .
5.2 Example 1
This is a sample response to the first example request:
123422 May 2001ACME, Inc.SuccessValid1helloSuccessValid2goodbye
10
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 11
...
...
11
Page 12 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
5.3 Schema
XML Schema for X-BULK version 1.1 draft 4
12
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 13
13
Page 14 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
6 WSDL
14
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 15
15
Page 16 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
16
XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4 Page 17
7 Authors
Stephen Farrell, Baltimore Technologies, *******.*******@*********.**
Merlin Hughes, Baltimore Technologies, ******@*********.**
Niall O'Sullivan, Baltimore Technologies, **********@*********.***
Patrick George, Gemplus, *******.******@*******.***
Fran ois Rajchenbach, Oberthur Card Systems, *.***********@**********.***
Jean-Claude Perrin, Schlumberger, ******@*********.**.***.***
Thanks also to Pierre Heuze (Cardbase) and James Webster (Cards etc) for commenting
on earlier versions of the specification.
The authors would also like to acknowledge the authors of, and contributors to, the base
XKMS specification, in particular Warwick Ford and Phill Hallam-Baker of Verisign.
17
Page 18 XML Key Management Specification Bulk Operation (X-BULK) v1.1 draft 4
Appendix A References
[PKCS#1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
RFC 2313, March 1998.
[PKCS#10] Kaliski, B., Nystrom, M., "PKCS #10: Certification Request
Syntax Specification Version 1.7" RFC 2986, November 2000.
[WSDL] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web
Services Description Language (WSDL) 1.0 September 25, 2000,
http://www.w3.org/TR/wsdl
[XKMS] P. Hallam-Baker et al, "XML Key Management Specification",
World Wide Web Consortium, http://www.w3.org/TR/xkms
[XMLDSIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer, B. Fox, E. Simon.
XML-Signature Syntax and Processing, World Wide Web
Consortium. http://www.w3.org/TR/xmldsig-core/
Appendix B Legal Notices
Baltimore Technologies, Gemplus, Oberthur Card Systems, and Schlumberger hereby grant to
the W3C, a perpetual, nonexclusive, non-sublicensable, non-assignable, royalty-free, worldwide
right and license under any copyrights in this contribution to copy, publish, and distribute the
contribution, as well as a right and license of the same scope to any derivative works prepared by
the W3C and based on, or incorporating all or part of the contribution.
Baltimore Technologies, Gemplus, Oberthur Card Systems, and Schlumberger further agree that,
upon submission of this contribution to the W3C, Baltimore, Gemplus, Oberthur Card Systems,
and Schlumberger will grant to any party a royalty-free license on other reasonable and non-
discriminatory terms under their applicable intellectual property rights essential to implement and
use the technology proposed in this contribution in products that comply with this contribution, but
only for the purpose of complying with this contribution. Baltimore Technologies, Gemplus,
Oberthur Card Systems, and Schlumberger expressly reserve all other rights they may have in
the material and subject matter of this contribution. The licensing commitments made hereunder
do not include any license for implementation of other published specifications developed
elsewhere but referred to in this contribution.
This contribution is being provided AS IS, and BALTIMORE, GEMPLUS, OBERTHUR CARD
SYSTEMS, AND SCHLUMBERGER EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES
REGARDING THIS CONTRIBUTION, INCLUDING ANY WARRANTY THAT THIS
CONTRIBUTION DOES NOT VIOLATE THE RIGHTS OF OTHERS OR IS FIT FOR A
PARTICULAR PURPOSE.
18
gnable, royalty-free, worldwide
right and license under any copyrights in this contribution to copy, publish, and distribute the
Contact this candidate