XML Key Management Requirements

W3C Working Draft 23 November 2001

This version:: http://www.w3.org/2001/XKMS/Drafts/xkms-req-20011123.html
Latest version:: http://www.w3.org/2001/XKMS/Drafts/xkms-req.html
Previous version:: http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/att-0007/01-xkms-reqNov8.html
Editors:: Frederick Hirsch, Zolera Systems, Inc. <fjh@alum.mit.edu>; Mike Just, Entrust, Inc., <mike.just@entrust.com>

Copyright ©2001 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This document lists the design principles, scope and requirements for ~~the~~ XML Key Management specifications. It includes requirements as they relate to the key management syntax, processing, security and external requirements and coordination.

Status of this Document

This is a 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], XML Trust Center Change Proposal [XKMSChange], and from the July 2001 Workshop position papers [XKMSPositionPapers] and Workshop meeting minutes [XKMSWorkshopMinutes]. Several additions and modifications have been included in this draft, reflecting comments from the mail list [XKMSWorkshopList], and Nov 14, 2001 teleconference [RequirementsTeleCon].

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

These requirements will be reflected in the XKMS recommendation, as well as additional optional recommendations in the XKMS work group charter, such as Bulk Key registration. Wherever "specification" is used in this document, it refers to the core XKMS recommendation as well as any additional associated specifications.

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

Table of Contents

Introduction
1. Terminology
Design Principles and Scope
Requirements
References

1. Introduction

XML-based cryptographic key management should be designed to meet two general goals. The first is to support a simple client to make use of sophisticated key management functionality. The second is to provide key management support to XML applications that is consistent with the XML [XML] architectural approach. In particular, it is a goal of XML key management to support the key management requirements of XML Encryption [XML Encryption], and XML Digital Signature [XMLDSIG]. Although directed primarily at public key management, the key management mechanisms could also be applied to symmetric key management. This specification provides the requirements for XML key management to achieve these goals.

1. Terminology

Assertion: An (trust) assertion consists of a statement securely bound to a unique identifier. Assertions may be used to establish and manage long term trust relations between principals. For the purposes of the XML Key Management specification, `assertion' indicates a key assertion that binds a unique identifier to a cryptographic key.
Client: An application that makes requests of a service. The concept of a `client' is relative to a service request; an application may have the role of client for some request and service for others.
Service: An application that provides computational or informational resources on request. A service may be provided by several physical servers operating as a unit.
Trust Service: A service that is capable of validating secured requests and/or producing secured responses, where trust in a request or response between the client and service may be based in part on successful validation of an assertion.
Web Service: A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions.

2. Design Principles and Scope

This section describes high level principles of design and definition of scope. They are an expression of intent. How they are realized is addressed in subsequent sections.

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 SOAP 1.1 [SOAP] and migrate to XML Protocol [XMLProtocol] once defined [List(Blair Dillaway)].
The design will be transport protocol agnostic and not rely upon lower protocols for functionality. [List(Blair Dillaway)]
The specification must ensure the correspondence of responses with requests, to enable definitive evidence trails as well as to aid correlation of asynchronous responses with requests. As an example, suppose that a client were to request the validation of a KeyName and KeyValue but the request were constructed such that only an indication of success was returned. It is possible then that the client is not able to ensure that the response matches the original request. A possible implementation is to require responses to include a hash of the request.
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 precludesmall footprint clients and low bandwidth solutions. The protocols should be lightweight.
The specification should clearly define the set of responses expected by a client for a each type of request and clearly define the expected actions of a client receiving those responses. For example, responses that apply to a validation request, will not necessarily apply to a registration request.
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]
The specification should be useful for processing all <ds:KeyInfo> elements, including those for symmetric keys. It is expected that the primary application will be for public keys, but symmetric key processing may be necessary for XML encryption clients.

2. Security Model

The specification must recognize the options for securing a message's confidentiality and integrity. Requirements for profiling these options are included below. In particular, the specification should indicate the preferred level of security required for each message. For example, a location request of a trust assertion would not typically require further protection of the service response in case the validation of the returned trust assertion is performed at the client. However, if the service returned only the individual assertion components (e.g. the public key and the unique identifier), without their cryptographic binding (e.g. the certificate signature) then integrity protection of the components would be required.

The specification will define how XML Key Management messages and transactions can be secured (for confidentiality and integrity) where
1. the specification will not solely rely upon SOAP or other application transport security;
2. "direct" message and transaction security will be based on XML Encryption and XML Signature. Therefore, the specification must describe how XML Encryption [XMLEncryption] may be used for confidentiality protection of request or response contents, independent of transport mechanism. The specification must also describe how XML Digital Signatures [XMLDSig] may be used for authenticity of requests or response contents, independent of transport mechanism.
3. The specification must define how the use of transport layer security such as SSL/TLS, IPSec or Signed/Encrypted SOAP/XML Protocol can be used to protect connections over which XKMS messages/transactions are transported

The specification will define which of the security mechanisms are mandatory, recommended, optional, etc. [List].
The specification should support different means of establishing a trust relationship with the XKMS Trust Server, and not be limited to client caching of a trusted certificate or trusted key for an XTAML [XTAML] assertion.
The specification security section should discuss protection against replay attacks using either nonce, origination time, serial number in requests. This should be recommended in security section. The specification should not preclude these techniques, and should define optional mechanisms.
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.
The specification must state in the security section that concerns over the privacy of registration information may be addressed through server P3P privacy policies. The definition and retrieval mechanisms for these policies are defined in the P3P recommendation and do not require definition in the XKMS specifications [P3P].
The security section of the specification should recommend that at least one form of integrity and confidentiality protection of service requests and responses be taken by applications, either transport security or integrated signature and encryption protection.

3. 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 support roaming [List(Blair Dillaway)] and private key recovery.
~~The specification must define how to obtain a privacy statement from the server, such as a P3P privacy statement.~~

4. 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]

5. Public Key Service Design

1.Location

The specification must define a request for retrieving a public key, given a <ds:KeyInfo> element containing one or more key attributes. 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. As another example, the context may include the trust anchors and certificate policies the client wants the server to user for validation. [List(Yassir Elley)]

The XKMS recommendation should not impose client XKMS capabilities - clients should implement the minimum that they need. The specification should define the wire protocol be implemented , and requirements on compliant Trust Server implementations.

6. 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 key authority delegation [XTAML]. This does not preclude requiring the ability to sign/encrypt requests and responses, nor preclude discussion of establishing trust with the XKMS Trust server. [List (Stephen Farrell)]
The XKMS recommendation will not define generic mechanisms for securing SOAP or XML Protocol, but rather define the mechanisms necessary to secure XKMS while reducing external standards dependencies. [List(Blair Dillaway)]
Issues of anonymous access and service use are out of scope.

3. Requirements

1 . Trust Server

Ability to store and retrieve encrypted private key at server, without server having key in clear. [Verisign XKMS Change Proposal]
Provide server introspection - means to request and obtain response indicating services trust server supports (RetrievalMethod, Locate, Validate etc.)
Selection of services should use standard HTTP binding techniques such as URLs, rather than requiring the XKMS protocol to define this functionality. For example, a URL may be used to define access to a trust service and possibly distinguish the underlying technologies (e.g. PGP, X509 etc.).
The specification should required the ability to support asynchronous registration responses.
More generally, the specification should allow asynchronous transport of both registration and service responses, but not require this of Trust servers. s~~upport Server may support pending responses, where the response must be retrieved later by the client, optionally after a server notification.~~

2. Web Service Definition

The specification must define payload and header XML formats, providing SOAP 1.1 bindings and XML Protocol bindings once XML Protocol is defined. XML Protocol bindings may be published as a separate document from the XKMS recommendation, to avoid dependencies on the XML Protocol schedule. SOAP 1.1 need not be the only binding defined, but is required. [List(Blair Dillaway)]
The server must support a set of required SOAP 1.1 bindings (migrate to XML Protocol when that becomes available).
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.
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 the <Respond> element in <Locate> and <Validate> requests (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 and KeyValue.

The following KeyInfo formats SHALL be supported if the service supports interoperability with X509: X509Cert and X509Chain.

The following KeyInfo formats MAY be supported: X509CRL, OCSP,RetrievalMethdod,MgmtData, PGP, PGPWeb, SPKI

The XKMS registration Private format which SHALL be supported if the service support either service generated key pairs or key recovery. [List(Sébastien Pouliot)]

The following assertions must be supported ValidityInterval: NotBefore, NotAfter

4. Processing

Exclusive Canonicalization [ExclusiveCanonicalization] support is required to assure robust XML digital signatures when the context of the XKMS content may be changed, such as in the case of intermediate SOAP processors altering the SOAP envelope context.

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.

b. Registration

The specification should ~~not preclude the use of different authentication mechanisms.~~ be compatible with the use of authentication mechanisms carried in a SOAP/XML Protocol messages and/or the transport protocol. XKMS should not define an authentication mechanism beyond key proof of possession.
The specification must describe how to provide proof of possession of private keys, for both signing and encryption keys.
The specification should allow use of user-generated pass phrases as a means of proving ownership of a key(s) previously registered.
The specification should provide a means of employing a secret, arranged out-of-band, between the registration service and end-user as a means of authorizing a registration action. [List(Blair Dillaway)]

6. Coordination

Key Management

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

The XKMS working group shall track the XML Query activity and make use of the technology as appropriate without creating a dependency on that activity.

7 Intellectual Property

4. References

DOM: Document Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft. January 2001.

XKMS Workshop Mail List
http://lists.w3.org/Archives/Public/www-xkms-ws/
XKMS Requirements Teleconference
http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0028.html
XML: Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.; http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N: Canonical XML. W3C Recommendation. J. Boyer. March 2001.; http://www.w3.org/TR/2001/REC-xml-c14n-20010315

URI: RFC2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998