XML Key Management Requirements

W3C Working Draft 23 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 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

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

    1. Terminology

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 SOAP 1.1 [SOAP] and migrate to XML Protocol [XMLProtocol] once defined [List(Blair Dillaway)].
    4. The design will be transport protocol agnostic and not rely upon lower protocols for functionality. [List(Blair Dillaway)]
    5. 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.
    6. Privacy considerations must be addressed.
    7. The specification must clarify the distinction between service tiers {Reagle} - [WorkshopMinutes]
    8. 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].
    9. The specification should not precludesmall footprint clients and low bandwidth solutions. The protocols should be lightweight.
    10. 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.
    11. 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]
    12. 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.
    1. 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
    2. [List]

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

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

5. Public Key Service Design


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

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

  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 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)]
  12. 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)]
  13. Issues of anonymous access and service use are out of scope.

3. Requirements

1 . Trust Server

    1. Ability to store and retrieve encrypted private key at server, without server having key in clear. [Verisign XKMS Change Proposal]
    2. Provide server introspection - means to request and obtain response indicating services trust server supports (RetrievalMethod, Locate, Validate etc.)
    3. 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.).
    4. The specification should required the ability to support asynchronous registration responses.
    5. More generally, the specification should allow asynchronous transport of both registration and service responses, but not require this of Trust servers. support 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. 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)]
    2. The server must support a set of required SOAP 1.1 bindings (migrate to XML Protocol when that becomes available).
    3. Define means to convey application context in requests/responses, e.g. transaction amount, arbitrary XML {Microsoft, Sun}
    4. All formats should permit application/trust server extension through the use of additional elements in another namespace.
    5. Provide unified request/response mechanism across services (Locate, Validate etc.), including uniform error responses, query and response formats.
    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 the <Respond> element in <Locate> and <Validate> requests (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 and KeyValue.

    5. 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)]

4. Processing

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

b. Registration

      1. 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.
      2. The specification must describe how to provide proof of possession of private keys, for both signing and encryption keys.
      3. The specification should allow use of user-generated pass phrases as a means of proving ownership of a key(s) previously registered.
      4. 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

    The XML Key Management 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
    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.

    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.
P3P Working Draft
XKMS Charter
XKMS Workshop Meeting Minutes
 XKMS Workshop Position Papers
XKMS 1.1 W3C Note
XKMS Change Proposal
XKMS Workshop Mail List
XKMS Requirements Teleconference
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