XML Key Management Requirements

W3C Working Draft 8 November 2001

This version:: http://www.w3.org/TR/2001/
Latest version:: http://www.w3.org/TR/
Previous version:: None.
Editors:: Frederick Hirsch, Zolera Systems, Inc. <fjh@alum.mit.edu>; Mike Just, Entrust, Inc., <mike.just@entrust.com>

Abstract

Status of this Document

This is the first Working Draft of requirements for the (not yet officially formed) XML Key Management Working Group and has no official standing. This current draft contains the random thoughts of the editors and includes requirements from the XML Key Management Working Group Proposal [XKMSProposal], Proposed Charter [XKMSCharter],and from the July 2001 Workshop position papers [XKMSPositionPapers] and Workshop meeting minutes [XKMSWorkshopMinutes].

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." A list of current W3C working drafts can be found at http://www.w3.org/TR/.

Please send comments to the editors <fjh@alum.mit.edu>, <mike.just@entrust.com> and cc: the (temporary) list www-xkms-ws@w3c.org

2. Design Principles and Scope

1. Universality and Usability

Request and response messages should be extensible.
All messages and data structures must be specified in XML, using XML Schema [XMLSchema].
The specification must provide a binding to the XML Protocol [XMLProtocol].
The specification must describe how XML Encryption [XMLEncryption] may be used for confidentiality protection of request or response contents.
The specification must describe how XML Digital Signatures [XMLDSig] may be used for authenticity of requests or response contents.
The specification must ensure the correspondence of responses with requests.
Privacy considerations must be addressed.
The specification must clarify the distinction between service tiers {Reagle} - [WorkshopMinutes]
The specification should not require clients to implement traditional PKI processing such as ASN.1, certificate revocation or certificate chain processing, to obtain the benefits of public key technology. Usability and simplicity are paramount {Reuters} [XKMSPositionPapers].
The specification should not preclude small footprint clients and low bandwidth solutions. The protocols should be lightweight.
The specification should clearly define the set of responses expected by a client and clearly define the expected actions of a client receiving those responses.
Underlying PKI or other trust server mechanisms should be transparent to the client, with exception that credentials such as X.509 certificates may be explicitly retrieved. This should leverage the <ds:KeyInfo> work. {IAIK position} [XKMSPositionPapers]

2. Key Registration and Management Design

The specification must describe how to register key information, and in particular, associate additional information with the public key. A public key pair may be generated at a client and the public key registered with the trust service; a key pair may be generated at the trust service and the private key may be delivered to the client.
The specification must describe how to request the revocation of a registered public key assertion.
The specification must describe how to request the update to registered public key information.
The specification must describe how to request the recovery of private key information, corresponding to registered public key information.
The specification must define how to obtain a privacy statement from the server, such as a P3P privacy statement.

3. Bulk Key Registration

The specification must describe how to register more than one public key in a single registration request.
The specification must describe how to request an update as to the status of a multi-key request.
The specification must describe how to support template bulk registration with server generation. {Verisign} [WorkshopMinutes]

4. Public Key Service Design

1.Location

The specification must define a request for retrieving a public key, given a <ds:KeyInfo> element. The mechanism of processing KeyInfo and obtaining the key is not specified by XKMS, but rather the mechanism for requesting and obtaining the result.

2. Validation

This specification must describe how to validate the status of a public key and additionally validate the binding between a public key and other related information.
The specification must describe how a client can specify or determine the context in which a public key assertion will be validated {Certicom, Microsoft, Sun, Zolera} [XKMSPositionPapers]. Context enables 4-corner model support for example.

5. Out of Scope

Design of new cryptographic algorithms.
Issues of Non Repudiation, including but not limited to 'technical non-repudiation' and 'contractual non-repudiation'.
Sources of Trusted Time.
Models and data structures for establishing inter-domain trust, including but not limited to 'cross-certification'.
Expression of existing PKI data structures in XML.
Specification of inter-domain trust semantics.
Authorization and Authorization Assertions.
Attribute Certificates.
Knowledge representation syntax.
Audit management.
Establishment of trust server trust [XTAML].

3. Requirements

1 . Trust Server

Ability to store and retrieve encrypted private key at server, without

Verisign XKMS Change Proposal

Provide server introspection - means to request and obtain response

The server must support a set of required SOAP bindings (migrate to XML Protocol when that becomes available).
URL is to be used to define trust service and distinguish underlying technologies (e.g. PGP, X509 etc.). In other words a given trust service may only support one technology per URL interface.
Server may support pending responses, where the response must be retrieved later by the client, optionally after a server notification.

2. Web Service Definition

Define payload and header XML formats, providing SOAP bindings. SOAP not the only binding, but must be defined (XML Protocol)
Define means to convey application context in requests/responses, e.g. transaction amount, arbitrary XML {Microsoft, Sun}
All formats should permit application/trust server extension through the use of additional elements in another namespace.
Provide unified request/response mechanism across services (Locate, Validate etc.), including uniform error responses, query and response formats.
Prevent replay attacks using either nonce, origination time, serial number in request. This should be recommended in security section. The specification should not preclude these techniques, and should define optional mechanisms.
Permit opaque data to be associated with request and returned with response.

a. Requests

Clarify which requests can be idempotent (can repeat without ill effect), and which cannot.
Provide means to match requests and responses with server for transaction histories.
Require <ds:RetrievalMethod> functionality, ability to return <ds:KeyInfo> in response to request.
Use schema typing and namespace support for response values (rather than strings). {Reagle}, [WorkshopMeeting]
Validate request may also include values to be Located and returned in response. These MAY/MUST be included in validation portion of request

b. Responses

The specification must allow the server to return a subset or superset of the elements requested by the clients. {Reagle} [WorkshopMeeting]
The specification should define a mechanism so that responses include both a list of valid assertions, and a list of invalid assertions, removing the ambiguity possible with valid, invalid and indeterminate assertion status possibilities combined with a single type of response. {Salz} [XKMS developers list]

3. Objects

The specification should define how to register a key for specific uses and how to update the allowed uses over time. [XKMSPositionPapers ]
The specification should enable finer granularity of key usage definition to support compliance requirements. Signatures may be supported for specific purposes, such as approval, authorship or integrity for example. One possible way of meeting this requirement is to define a <Purpose> subtype for the <KeyUsage> element.
Assertions may/must have issuers associated with them.
The following KeyInfo formats MUST be supported: KeyName, KeyValue, X509Cert, X509Chain. The following KeyInfo formats MAY be supported: X509CRL, OCSP,RetrievalMethdod,MgmtData, PGP, PGPWeb, SPKI, Multiple...(in addition to the XKMS registration Private format which MUST be supported)
The following assertions must be supported ValidityInterval: NotBefore, NotAfter

4. Processing

a. Parsing

XML Key Management applications must be XML-namespaces [XML-namespaces] aware.
XML Key Management applications must be XML Schema [XML-schema] aware in that they create XML Key Management instances conforming to the key management schema definitions. {Reagle}
Implementation of the specification should work with existing XML parser and schema implementations. However, alterations to particular DOM and/or XML parser implementations may prove beneficial in terms of simplifying application development or improving runtime efficiency. These details are outside the scope of the XML Key Management specification.
Support Exclusive Canonicalization [ ExclusiveCanonicalization ] of message content, especially assertions.

b. Registration

The specification should not preclude the use of different authentication mechanisms.
The specification must describe how to provide proof of possession of private keys.

5. Security

The XML Key Management specification must include a discussion of potential vulnerabilities and recommended practices when using the defined processing model in a larger application context. While it is impossible to predict all the ways an XML Key Management standard may be used, the discussion should alert users to ways in which potentially subtle weaknesses might be introduced.

At a minimum, security issues arising from known plain-text and data length information must be addressed.

6. Coordination

The XML Encryption specification should meet the requirements of (so as to support) or work with the following applications:

To ensure the above requirements are adequately addressed, the XML Key Management specification must be reviewed by a designated member of the following communities:

XML Signature WG
XML Encryption WG
XML Protocol
XML Schema WG
XML Core WG
Internationalization IG

7 Intellectual Property

The specification should be free of encumbering technologies: requiring no licensing fees for implementation and use.