W3C

XML Key Management Requirements

W3C Working Draft 19 December 2001

This version:
http://www.w3.org/2001/XKMS/Drafts/xkms-req-20011219.html
Latest version:
http://www.w3.org/2001/XKMS/Drafts/xkms-req.html
Previous version:
http://www.w3.org/2001/XKMS/Drafts/xkms-req-20011123.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 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 first release of specifications from the XML Key Management Working Group. Previous drafts of this document reflected requirements from various sources, including the XML Key Management Working Group Proposal [XKMSProposal], Charter [XKMSCharter], XML Trust Center Change Proposal [XKMSChange], July 2001 Workshop position papers [XKMSPositionPapers] and Workshop meeting minutes [XKMSWorkshopMinutes], comments from the (temporary) mail list [XKMSWorkshopList], and the November 14, 2001 teleconference [RequirementsTeleCon]. This latest version incorporates discussion from the December 9, 2001 XKMS requirements meeting.

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 mailing list: www-xkms@w3.org

Table of Contents

  1. Introduction
    1. Terminology
  2. Design Principles and Scope
    1. Universality and Usability
    2. Security Model
    3. Protocol Design
    4. Out of Scope
  3. Requirements
    1. Trust Server
    2. Payload and Protocol Definition
    3. Objects
    4. Processing
  4. Coordination
  5. Intellectual Property
  6. 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]. This specification provides the requirements for XML key management to achieve these goals for the first release of specifications from this working group.

1. Terminology

Asynchronous exchange
An exchange where the synchronous service response is incomplete, requiring the client to perform a subsequent request at some later time.  For XML Key Management all requests producing an asynchronous result require a synchronous response status of "Pending".
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.
Deferred Authentication
A mechanism to allow a client to verify that the server processed the correct request at the correct service interface (URI) by referencing the request in the response. The client may verify the server input by comparing a digest of the request with a digest returned in a secured response. This ensures that an attacker has not diverted a request, ensuring that the expected server policy was followed and that the request was conveyed correctly.
Key Validation
A service that verifies the binding of elements to a public key and also determines the validity status of the public key. For example, key validation may be performed based on elements secured to a public key in an X.509 certificate as in RFC 2459.
KeyBinding
An XML element suitable for associating additional elements with a public key as contained in a <ds:KeyInfo> element. This element might be used to convey status and validity period information for key validity queries or used to convey private key information as part of a registration request or response.
KeyName
A property defined in the XML Digital Signature recommendation, allowing a name to be associated with a key within a <ds:KeyInfo> element. This may be associated with a key in registration, but is not required and not required to be a unique identifier for a key.
Pass phrase
A key derived from a pass phrase may be provided for authentication in circumstances where public key based authentication is not possible.
Proof of possession (POP)
Performing an action with a private key to demonstrate possession of the key. An example is creating a signature using the private key being registered, to prove ownership of that key.
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 registering public keys and/or providing key information services, including key validation and location.
Web Service
A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions, including XML Protocol (or until XML protocol is standardized, SOAP). Web service may also imply the use of ancillary mechanisms, such as WSDL for defining Web services interfaces.

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. Element cardinality not equal to one, must be justified in the specification. Similarly, the use of optional elements should be justified.
  4. The specification must provide a binding to SOAP 1.1 [ SOAP ] and migrate to XML Protocol [XMLProtocol] once defined [List(Blair Dillaway)]. Interoperable SOAP support is required, e.g. Document literal encoding for compatibility with KeyInfo.
  5. The design will be transport protocol agnostic - SOAP content may be carried over different transport protocols. [List(Blair Dillaway)]
  6. The specification must ensure the correspondence of responses with requests, aiding correlation of asynchronous responses with requests and also ensuring that the appropriate request was processed according to the expected policy.
  7. Privacy considerations must be addressed.
  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 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.
  10. 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]
  11. A mechanism for versioning should be defined. If a good reason exists for an approach other than XML Namespaces, it should be justified.
  12. Support for legacy formats such as PKCS#10 and PKCS#7 should be defined.

2. Security Model

The specification must define options for securing a message's confidentiality and integrity.
  1. Every trust responder must support all three integrity and confidentially mechanisms: SSL, payload security, and no-security (the assumption of no-security is that security will be provided by another mechanism such as IPSec). Every client must support one of the mechanisms.
  2. 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 payload protection.
  3. Payload security must be based on XML Encryption and XML Signature and be used to secure the body content of XML Key Management SOAP messages. Individual elements of XML Key Management protocol messages will not be encrypted.
  4. The specification will define how XML Key Management messages and transactions can be secured (for confidentiality and integrity) where payload security is not implemented.
  5. The specification must profile TLS for interoperable use for XML Key Management.
  6. 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.
  7. The specification should support different means of establishing a trust relationship with the Trust Service, and not be limited to client caching of a trusted certificate or trusted key for an XTAML [XTAML] assertion.
  8. 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.
  9. 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.
  10. 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].
  11. [The server service authentication key must be available for direct use by clients, such as in <Ds:KeyValue> format.]
  12. All trust server responses must always include a digest of the request payload and the request URL.

3. Protocol 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 private key recovery.
  5. The specification must describe how to register more than one public key in a single registration request.
  6. The specification must describe how to request an update as to the status of a multi-key request.
  7. The specification must describe how to support template bulk registration with server generation. {Verisign} [WorkshopMinutes]
  8. 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 implementation dependent, but a server must be able to return key information corresponding to a KeyInfo returned in a registration response from the same server.
  9. 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.
  10. 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)]

4. Out of Scope

These items are out of scope (at least for the initial specifications produced by the working group).
  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 XML Key Management recommendation will not define generic mechanisms for securing SOAP or XML Protocol, but rather define a payload security mechanism. A goal is to reduce external standards dependencies. [List(Blair Dillaway)]
  13. Issues of anonymous access and service use.
  14. Private key retrieval services that extend beyond the return of a service-generated private key as part of registration (e.g. Roaming).
  15. Server chaining and referral mechanisms.
  16. XML Key Management of symmetric keys.
  17. Caching support.

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

2. Payload and Protocol 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. 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. Permit opaque data to be associated with request and returned with response.
  6. Clarify which requests can be idempotent (can repeat without ill effect), and which cannot.
  7. Provide means to match requests and responses with server for transaction histories.
  8. A client should be able to control the number of responses returned (e.g. specify the maximum to be returned).
  9. Use schema typing and namespace support for the <Respond> element in <Locate> and <Validate>  responses (rather than strings). {Reagle}, [WorkshopMeeting]
  10. Validate request may also include values to be Located and returned in response. These MAY/MUST be included in validation portion of request.
  11. The specification must allow the server to return a subset or superset of the elements requested by the clients. {Reagle} [WorkshopMeeting]
  12. 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.
    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,RetrievalMethod,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. XML Key Management applications must be XML-namespaces [XML-namespaces] aware.
  3. 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}
  4. 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.
  5. The specification should 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.
  6. The specification must describe how to provide proof of possession of private keys.
  7. The specification should allow use of user-generated pass phrases as a means of proving ownership of a key(s) previously registered.
  8. 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)]
  9. The KeyInfo returned in a registration response should be a unique key identifier for the responder for subsequent service requests. Subsetting this KeyInfo may make this not true. Server implementations may define uniqueness properties and relate them to clients - how this is done is implementation dependent.

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

5 -- Intellectual Property

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

6 -- References

DOM
Document Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft. January 2001.
http://www.w3.org/TR/DOM-Level-3-Core/core.html
Exclusive Canonicalization - work in progress
http://www.w3.org/Signature/Drafts/xml-exc-c14n.html
InfoSet
XML Information Set, W3C Proposed Recommendation. John Cowan. August 2001.
http://www.w3.org/TR/2001/PR-xml-infoset-20010810/
MIME
RFC2046. MIME Part Two: Media Types  November 1996.
http://rfc.net/rfc2046.html
P3P Working Draft
http://www.w3.org/TR/P3P/
SOAP
Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/SOAP/
XKMS Charter
http://www.w3.org/2001/XKMS/2001/01/xkms-charter.html
XKMS Workshop Meeting Minutes
http://www.w3.org/2001/07/xkms-ws/minutes.html
 XKMS Workshop Position Papers
http://www.w3.org/2001/07/XKMS-Ws/positions/
XKMS-Proposal
http://lists.w3.org/Archives/Public/www-xkms-ws/2001Aug/att-0048/02-xkms-activity.html
XKMS 1.1 W3C Note
http://www.w3.org/TR/xkms/
XKMS Change Proposal
http://www.xmltrustcenter.org/xkms/docs/xkms_change_proposal.html
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
http://www.ietf.org/rfc/rfc3076.txt
XML-ns
Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.
http://www.w3.org/TR/1999/REC-xml-names-19990114/
XML-schema
XML Schema Part 1: Structures W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001.
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. May 2001.
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
XMLDSIG
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
http://www.w3.org/2000/xp/
XSet
Full Fidelity Information Set Representation. Jonathan Borden. XML-Dev
http://lists.xml.org/archives/xml-dev/200008/msg00239.html
XTAML
http://www.xmltrustcenter.org/research/xtaml/index.htm
URI
RFC2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998
http://www.ietf.org/rfc/rfc2396.tx