XML Key Management Requirements

W3C Working Draft 8 November 2001

This version:
Latest version:
Previous version:
Frederick Hirsch, Zolera Systems, Inc. <fjh@alum.mit.edu>
Mike Just, Entrust, Inc., <mike.just@entrust.com>


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

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

Table of Contents

  1. Introduction
  2. Design Principles and Scope
    1. Universality and Usability
    2. Key Registration and Management
    3. Bulk Key Registration
    4. Public Key Service Design
      1. Location
      2. Validation
    5. Out of Scope
  3. Requirements
    1. Trust Server
    2. Web Service Definition
    3. Objects
    4. Processing
    5. Security
    6. Coordination
    7. Intellectual Property
  4. 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.

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

    1. Request and response messages should be extensible.
    2. All messages and data structures must be specified in XML, using XML Schema [XMLSchema].
    3. The specification must provide a binding to the XML Protocol [XMLProtocol].
    4. The specification must describe how XML Encryption [XMLEncryption] may be used for confidentiality protection of request or response contents.
    5. The specification must describe how XML Digital Signatures [XMLDSig] may be used for authenticity of requests or response contents.
    6. The specification must ensure the correspondence of responses with requests.
    7. Privacy considerations must be addressed.
    8. The specification must clarify the distinction between service tiers {Reagle} - [WorkshopMinutes]
    9. 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].
    10. The specification should not preclude small footprint clients and low bandwidth solutions. The protocols should be lightweight.
    11. 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.
    12. 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

    1. 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.
    2. The specification must describe how to request the revocation of a registered public key assertion.
    3. The specification must describe how to request the update to registered public key information.
    4. The specification must describe how to request the recovery of private key information, corresponding to registered public key information.
    5. The specification must define how to obtain a privacy statement from the server, such as a P3P privacy statement.

    3. Bulk Key Registration

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

    4. Public Key Service Design


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

      1. 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.
      2. 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

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

3. Requirements

1 . Trust Server

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

    2. server having key in clear. [Verisign XKMS Change Proposal]
    3. Provide server introspection - means to request and obtain response

    4. indicating services trust server supports (RetrievalMethod, Locate, Validate etc.)
    5. The server must support a set of required SOAP bindings (migrate to XML Protocol when that becomes available).
    6. 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.
    7. Server may support pending responses, where the response must be retrieved later by the client, optionally after a server notification.

    2. Web Service Definition

    1. Define payload and header XML formats, providing SOAP bindings. SOAP not the only binding, but must be defined (XML Protocol)
    2. Define means to convey application context in requests/responses, e.g. transaction amount, arbitrary XML {Microsoft, Sun}
    3. All formats should permit application/trust server extension through the use of additional elements in another namespace.
    4. Provide unified request/response mechanism across services (Locate, Validate etc.), including uniform error responses, query and response formats.
    5. 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.
    6. Permit opaque data to be associated with request and returned with response.
    7. a. Requests

      1. Clarify which requests can be idempotent (can repeat without ill effect), and which cannot.
      2. Provide means to match requests and responses with server for transaction histories.
      3. Require <ds:RetrievalMethod> functionality, ability to return <ds:KeyInfo> in response to request.
      4. Use schema typing and namespace support for response values (rather than strings). {Reagle}, [WorkshopMeeting]
      5. 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

      1. The specification must allow the server to return a subset or superset of the elements requested by the clients. {Reagle} [WorkshopMeeting]
      2. 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

    1. The specification should define how to register a key for specific uses and how to update the allowed uses over time. [XKMSPositionPapers ]
    2. 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.
    3. Assertions may/must have issuers associated with them.
    4. 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)
    5. The following assertions must be supported ValidityInterval: NotBefore, NotAfter

    4. Processing

    a. Parsing

    1. XML Key Management applications must be XML-namespaces [XML-namespaces] aware.
    2. 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}
    3. 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.
    4. Support Exclusive Canonicalization [ ExclusiveCanonicalization ] of message content, especially assertions.

b. Registration

    1. The specification should not preclude the use of different authentication mechanisms.
    2. 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:
    1. W3C XML Signature
    2. W3C XML Encryption
    3. W3C XML Protocol
    4. Oasis XML-Based Security Services TC (SSTC)
    To ensure the above requirements are adequately addressed, the XML Key Management specification must be reviewed by a designated member of the following communities:
    1. XML Signature WG
    2. XML Encryption WG
    3. XML Protocol
    4. XML Schema WG
    5. XML Core WG
    6. Internationalization IG

    Intellectual Property

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

4. References

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

Exclusive Canonicalization - work in progress
XML Information Set, W3C Proposed Recommendation. John Cowan. August 2001.
RFC2046. MIME Part Two: Media Types  November 1996.
XKMS Charter
XKMS Workshop Meeting Minutes
 XKMS Workshop Position Papers
XKMS 1.1 W3C Note
XKMS Change Proposal
Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.
Canonical XML. W3C Recommendation. J. Boyer. March 2001.

Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.
XML Schema Part 1: Structures W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001.

XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. May 2001.
XML-Signature Syntax and Processing. W3C Proposed Recommendation. D. Eastlake, J. Reagle, and D. Solo. August 2001. (http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/)
XML Signature Requirements . W3C Working Draft. J. Reagle. October 1999. (http://www.w3.org/TR/xmldsig-requirements )
XML Encryption
XML Encryption Syntax and Processing . W3C Working Draft. T. Imamura, B. Dillaway, J. Schaad, E. Simon. October 2001. (http://www.w3.org/TR/xmlenc-core/)
XML Encryption Requirements . W3C Working Draft. J. Reagle. October 2001. (http://www.w3.org/TR/xml-encryption-req)
XML Protocol
Full Fidelity Information Set Representation. Jonathan Borden. XML-Dev
RFC2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998