Baltimore XKMS Position Paper
=============================

Baltimore Technologies, 19th June 2001
Contact: sfarrell@baltimore.com, mhughes@baltimore.com

General
-------

Baltimore support the development of a W3C specification standardizing
XML key management, based on the current XKMS note. We believe that
this specification provides a sound starting point for development
and that W3C is the correct venue for such standardization. We would
propose the the scope of the putative group be kept fairly limited,
emphasizing in the first instance cases where an X.509 based PKI 
provides the "back-end" to an XKMS server. This is consistent with
the approach of XMLDSIG and the XLM encryption work, where 
interoperability work has focused on cases with X.509 based PKIs.

In addition we believe that bulk issuance functionality needs to
be added to XKMS as outlined below. 

Baltimore, together with GemPlus, Oberthur and Schlumberger will
provide a detailed specification of X-BULK prior to the XKMS 
workshop.

XKMS Bulk Operation (X-BULK)
----------------------------

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 analagous to seprated RAs and CAs from 
  the X.509 world

Key differences betweek 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 (aka card management systems)

X-BULK does however re-use 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.