WD-xkms2-req-20020318 39.7 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>XML Key Management (2.0) Requirements</title>
  <style type="text/css">
/**/

   u,ins,.ins           { background: white; color: red;}
   del,strike,.strike   { background: white; color: silver;
                          text-decoration: line-through;}
    code        {font-weight: normal; }
   .link-def    { background: #FFFFFF; color: teal;  font-style: italic;}
    .comment    { background: #FFFFF5; color: black; padding: .7em;
                  border: navy thin solid;}
   .discuss    { color: blue; background: yellow; }
   .xml-example,.xml-dtd { margin-left: -1em; padding: .5em;
                 white-space: pre; border: none;}
   .xml-dtd    { background: #efeff8; color: black;}


/**/
  </style>
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" type="text/css"
  rel="stylesheet" />
</head>

<body bgcolor="#FFFFFF">

<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72" /></a>

<h1>XML Key Management (2.0) Requirements</h1>

<h2>W3C Working Draft 18 March 2002</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/WD-xkms2-req-20020318">http://www.w3.org/TR/2002/WD-xkms2-req-20020318</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/xkms2-req">http://www.w3.org/TR/xkms2-req</a></dd>
  <dt>Previous version:</dt>
    <dd>n/a</dd>
  <dt>Editors:</dt>
    <dd>Frederick Hirsch, &lt;<a
      href="mailto:fjh@alum.mit.edu">fjh@alum.mit.edu</a>&gt;</dd>
    <dd>Mike Just, Entrust, Inc., &lt;<a
      href="mailto:mike.just@entrust.com">mike.just@entrust.com</a>&gt;</dd>
</dl>

<div class="copyright">
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
© 2002 <abbr title="World Wide Web Consortium"><a
href="http://www.w3.org/">W3C</a></abbr><sup>®</sup> (<abbr
title="Massachusetts Institute of Technology"><a
href="http://www.lcs.mit.edu/">MIT</a></abbr>, <abbr xml:lang="fr" lang="fr"
title="Institut National de Recherche en Informatique et Automatique"><a
href="http://www.inria.fr/">INRIA</a></abbr>, <a
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p>
</div>
</div>
<hr title="Separator from Header" />

<h2 class="abstract">Abstract</h2>
This document lists the design principles, scope and requirements for XML Key
Management specifications and trust server key management implementations. It
includes requirements as they relate to the key management syntax,
processing, security and coordination with other standards activities.

<div class="status">
<h2 class="abstract">Status of this Document</h2>

<div class="">
This is the <a
href="http://lists.w3.org/Archives/Public/www-xkms/2002Feb/0000.html">Last
Call</a> for the requirements Working Draft of the <a
href="http://www.w3.org/2001/XKMS/Overview.html">XML Key Management Working
Group</a> (<a href="http://www.w3.org/2001/XKMS/Activity.html">Activity
Statement</a>). This version represents the consensus of the Working Group.
The last call period is 3 weeks, ending on 15 April 2002.

<p>Previous drafts of this document reflected requirements from various
sources, including the XML Key Management Working Group Proposal [<a
href="#XKMSProposal">XKMSProposal</a>], Charter [<a
href="#XKMSCharter">XKMSCharter</a>], XML Trust Center Change Proposal [<a
href="#refxkmschange">XKMSChange</a>], July 2001 Workshop position papers [<a
href="#XKMSPositionPapers">XKMSPositionPapers</a>] and Workshop meeting
minutes [<a href="#ref-XKMSWorkshopMinutes">XKMSWorkshopMinutes</a>],
comments from the workshop and group mailing lists [<a
href="#ref-xkmsWorkshopMailList">Mailing Lists</a>]. This version also
incorporates discussion from the December 9, 2001 XKMS requirements meeting
and the November 14, 2001 and January 23, 2002 teleconference [<a
href="#ref-xkmsRequirementsTeleCon">Meetings</a>].</p>

<p>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 <a
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<p>These requirements will be reflected in the <a
href="http://www.w3.org/TR/xkms2/">XKMS specification</a>, 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 eventual core XKMS Recommendation as well as any additional
associated specifications.</p>

<p>Patent disclosures relevant to this specification may be found on the
Working Group's <a href="http://www.w3.org/2001/XKMS/Disclosures.html">patent
disclosure page</a> in conformance with W3C policy (at the time of writing
there are none there).</p>

<p>Please send comments to the editors &lt;<a
href="mailto:hirsch@zolera.com">fjh@alum.mit.edu</a>&gt;, &lt;<a
href="mailto:mike.just@entrust.com">mike.just@entrust.com</a>&gt; and cc: the
mailing list: <a href="mailto:www-xkms@w3.org">www-xkms@w3.org</a> (pubicly
<a href="http://lists.w3.org/Archives/Public/www-xkms/">archived</a>).</p>
</div>
</div>
<hr />

<h2 class="table-of-contents">Table of Contents</h2>
<ol class="table-of-contents">
  <li><a href="#sec-Intro">Introduction and Terminology</a><br />
  </li>
  <li><a href="#sec-Requirements">Requirements</a>
    <ol class="table-of-contents">
      <li><a href="#sec-general-design">Universality and Usability</a></li>
      <li><a href="#sec-security-model">Security Model</a></li>
      <li><a href="#sec-Server">Trust Server</a></li>
      <li><a href="#sec-protocol-design">Protocol Capabilities and
      Format</a></li>
      <li><a href="#sec-Objects">Objects and Processing</a></li>
    </ol>
  </li>
  <li><a href="#sec-scope">Out of Scope</a></li>
  <li><a href="#sec-Coordination">Coordination</a></li>
  <li><a href="#sec-IPR">Intellectual Property</a></li>
  <li><a href="#sec-References">References</a></li>
</ol>
<hr />

<h2><a name="sec-Intro" id="sec-Intro"></a>1 Introduction and Terminology</h2>
XML-based public key management should be designed to meet two general goals.
The first is to support a simple client's ability to make use of
sophisticated key management functionality. The second is to provide public
key management support to XML applications that is consistent with the XML
[<a href="#ref-XML">XML</a>] architectural approach. In particular, it is a
goal of XML key management to support the public key management requirements
of XML Encryption [<a href="#ref-xml-encryption">XML Encryption</a>] and XML
Digital Signature [<a href="#ref-xml-dsig">XMLDSIG</a>] and to be consistent
with the Security Assertion Markup Language [<a href="#ref-saml">SAML</a>].
This specification provides requirements for XML key management consistent
with these goals.

<p>The following terms and phrases are used throughout the remainder of this
draft.</p>
<dl>
  <dt>4-Corner Model</dt>
    <dd>A processing and/or trust environment where end-entities interact
      with a single trusted point of contact, and each such contact has a
      peerwise trust relationship with all other contacts.</dd>
  <dt>Asynchronous exchange</dt>
    <dd>An exchange where the synchronous service response is incomplete,
      requiring the client to perform a subsequent request at some later
      time.  For example, client registration may require time consuming
      checks where it is more practical for a client to return at a later
      time for their completed response. For XML Key Management all requests
      producing asynchronous results MUST produce a synchronous response
      status indicating an incomplete response, such as "Pending", for
      example. Such responses MAY also provide a URL for the client to check
      back to obtain the complete response at a later time.</dd>
  <dt>Client</dt>
    <dd>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.</dd>
  <dt>Deferred Request Authentication</dt>
    <dd>A mechanism to allow a client to verify that the server processed the
      correct request. The client may verify the server response, for
      example, by comparing the elements returned in the response, or
      comparing a digest of the request with a digest returned in a secured
      response. This ensures that an attacker has not diverted or otherwise
      changed portions of a request. For example, a client request might be
      directed to a particular URI so that a specific policy will be enforced
      as part of the service processing the request. Inclusion of the URI in
      the response ensures that the expected server policy was followed and
      that the request was conveyed correctly.</dd>
  <dt>Key Validation</dt>
    <dd>A service that verifies the binding of information to a public key
      and also determines the current status of that binding, if appropriate
      or possible for the information in question. For example, key
      validation may be performed based on elements secured to a public key
      in an X.509 certificate as outlined in PKIX [<a
      href="#ref-rfc-2459">RFC 2459</a>].</dd>
  <dt>Key Binding</dt>
    <dd>An XML element suitable for associating additional information with a
      public key. 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.</dd>
  <dt>Key Name</dt>
    <dd>A property defined in the XML Digital Signature recommendation,
      allowing a name to be associated with a key within a &lt;ds:KeyInfo&gt;
      element. The Key Name property is not required and when associated with
      a key in registration is not required to be a unique identifier for a
      key.</dd>
  <dt>Pass Phrase Key</dt>
    <dd>A key derived from a pass phrase may be used for authentication in
      circumstances where public key based authentication is not
    possible.</dd>
  <dt>Payload Security</dt>
    <dd>The XKMS request or response XML obtains integrity and/or
      confidentiality by being signed and/or encrypted, using an XML digital
      signature or XML encryption. The signature itself may be placed in the
      SOAP header when using a SOAP binding, for example. This is in contrast
      to transport integrity, where a SOAP message containing the XKMS
      payload is secured using TLS or other transport security
    mechanisms.</dd>
  <dt>Proof of Possession (PoP)</dt>
    <dd>Performing an action with a private key to demonstrate possession of
      the key. An example is creating a signature using a private signing key
      being registered, to prove possession of that key.</dd>
  <dt>Service</dt>
    <dd>An application that provides computational or informational resources
      on request. A service may be provided by several physical servers
      operating as a unit.</dd>
  <dt>TLS</dt>
    <dd>Transport Layer Security, a protocol layer designed to provide
      message integrity and confidentiality for a message during transit
      between two endpoints. An earlier version is known as SSL, the Secure
      Socket Layer [<a href="#ref-tls">TLS</a>].</dd>
  <dt>Trust Service</dt>
    <dd>A service that is capable of registering public keys and/or providing
      key information services, including key validation and location.</dd>
  <dt>Web Service</dt>
    <dd>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.</dd>
</dl>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119. [<a href="#ref-rfc-2119">RFC
2119</a>].</p>

<h2><a name="sec-Requirements" id="sec-Requirements"></a>2 Requirements</h2>
Familiarity with the W3C XKMS Note [<a href="#ref-xkms-note">XKMS Note</a>]
is assumed for this section.

<h3><a id="sec-general-design" name="sec-general-design"></a>2.1 Universality
and Usability</h3>
<ol>
  <li>Request and response messages SHOULD be extensible.</li>
  <li>All messages and data structures MUST be specified in XML, using XML
    Schema [<a href="#ref-XML-schema">XMLSchema</a>]. Schema validation is
    not required of applications or trust server implementations.</li>
  <li>Use of optional features is discouraged. Use of unbounded XML element
    schema definitions and optional elements SHOULD be justified.</li>
  <li>The specification MUST provide a binding to SOAP 1.1 [ <a
    href="#ref-soap">SOAP</a> ] and migrate to XML Protocol [<a
    href="#XMLprotocol">XMLProtocol</a>] once defined [List(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0026.html">Blair
    Dillaway</a>)]. The XKMS specification is required to profile SOAP for
    interoperability, including use of document literal encoding.</li>
  <li>The design MUST be transport protocol agnostic - SOAP content may be
    carried over different transport protocols. [List(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0026.html">Blair
    Dillaway</a>)]</li>
  <li>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.</li>
  <li>The specification SHOULD NOT require clients to implement traditional
    PKI processing such as ASN.1, certificate revocation or certificate chain
    processing. Usability and simplicity are paramount to enable client, to
    obtain the benefits of public key technology. {Reuters} [<a
    href="#XKMSPositionPapers">XKMSPositionPapers</a>].</li>
  <li>The specification SHOULD clearly define the set of responses expected
    by a client for 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.</li>
  <li>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 &lt;ds:KeyInfo&gt;
    work. {IAIK position} [<a
    href="#XKMSPositionPapers">XKMSPositionPapers</a>]</li>
  <li>A mechanism for versioning SHOULD be defined. If a good reason exists
    for an approach other than XML Namespaces, it MUST be justified.</li>
  <li>Server support for legacy formats such as PKCS#10 and PKCS#7 SHOULD be
    defined, but their support is OPTIONAL. An example use is in smartcard
    personalization or bulk registration applications.</li>
  <li>XKMS MUST be usable in a 4-corner application model. Specifically an
    XKMS server SHOULD be able to pass requests to another XKMS server for
    processing without excessive overhead. The definition of server chaining
    and referral messages are out of scope, but such mechanisms SHOULD not be
    precluded.</li>
</ol>

<h3><a id="sec-security-model" name="sec-security-model"></a>2.2 Security
Model</h3>

<div style="margin-left: 2em">
<p>[Data Confidentiality and Integrity]</p>
</div>
<ol>
  <li>Every trust service MUST support all three integrity and confidentially
    mechanisms: TLS, 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 at least one of these
  mechanisms.</li>
  <li>Payload security MUST be based on XML Encryption and XML Signature and
    MAY be useable to secure the body content of SOAP messages. Individual
    elements of XML Key Management protocol messages SHOULD not be encrypted,
    except for the Private element which is a special case (since it
    transports a private key) and MUST be encrypted using XML encryption.</li>
  <li>The specification MUST define how XML Key Management messages and
    transactions can be secured (for confidentiality and integrity) where
    payload security is not implemented. In particular, the specification
    MUST define how the use of transport layer security such as SSL/TLS. The
    specification MUST profile TLS, by requiring a subset of the defined
    cipher suites to be supported, for example.</li>
  <li>The security section of the specification SHOULD recommend that at
    least one form of integrity and confidentiality protection of service
    requests and responses be used by applications, either transport security
    or payload protection.
    <p>[Transaction Security]</p>
  </li>
  <li>All trust server responses MUST include a digest of the request payload
    and the request URL.</li>
  <li>Techniques for protection against replay attacks MUST be recommended in
    the security considerations section. Specific techniques SHOULD be
    defined, such as nonce, origination time, and serial numbers in requests,
    for example.
    <p>[Trust Service Trust]</p>
  </li>
  <li>The specification must indicate that trust services MUST make their
    public keying information (i.e. the public keys to be used to
    authenticate the trust service) publicly available in at least the
    &lt;ds:KeyValue&gt; format, since that is the minimal [<a
    href="#ref-xml-dsig">XMLDSIG</a>] key representation.</li>
  <li>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.
    <p>[Authentication]</p>
  </li>
  <li>The specification MUST allow use of user-generated pass phrases as a
    means of proving ownership of a key(s) previously registered key
  binding.</li>
  <li>The specification MUST provide a means of employing a secret, agreed
    out-of-band, between the registration service and end-user as a means of
    authorizing a registration action. [List(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0026.html">Blair
    Dillaway</a>)]
    <p>[Privacy]</p>
  </li>
  <li>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 [<a href="#ref-p3p">P3P</a>].
    <p>[Security considerations]</p>
  </li>
  <li>The 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 the specification 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.</li>
</ol>

<h3><a id="sec-Server" name="sec-Server"></a>2.3. Trust Server</h3>
<ol>
  <li>Provide server introspection - the means to request and obtain a
    response indicating services trust server supports (RetrievalMethod,
    Locate, Validate etc.)</li>
  <li>Selection of differently configured trust 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.).</li>
  <li>The specification SHOULD support asynchronous registration
  responses.</li>
  <li>More generally, the specification SHOULD allow asynchronous transport
    of both registration requests and responses, but not require this of
    trust servers.</li>
</ol>

<h3><a id="sec-protocol-design" name="sec-protocol-design"></a>2.4. Protocol
Capabilities and Formats</h3>

<div style="margin-left: 2em">
<p>[Capabilities]</p>
</div>
<ol>
  <li>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.</li>
  <li>The specification MUST describe how to revoke a registered key
  binding.</li>
  <li>The specification MUST describe how to update registered public key
    information.</li>
  <li>The specification MUST describe how to support a user recovering their
    own private key, such as might be needed to restore a lost private
    encryption key. This requirement does not imply any form of key escrow as
    used in the sense of mandated government access to private keys.</li>
  <li>The specification MUST describe how to register more than one public
    key in a single registration request, supporting bulk registration.</li>
  <li>The specification MUST describe how to request an update as to the
    status of a multi-key request.</li>
  <li>The specification MUST define a request for retrieving a public key,
    given a &lt;ds:KeyInfo&gt; element containing one or more children
    containing key information. 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. Population of the server
    database for responding to service requests (locate and validate) is out
    of scope and implementation specific.</li>
  <li>This specification MUST define a protocol for validating the status of
    a public key and additionally validating the binding between a public key
    and other related information.</li>
  <li>The specification MUST describe how a client can specify or determine
    the context in which a public key binding will be validated {Certicom,
    Microsoft, Sun, Zolera} [<a
    href="#XKMSPositionPapers">XKMSPositionPapers</a>]. 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 use for validation. [List(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0052.html">Yassir
    Elley)</a>]
    <p>[Formats]</p>
  </li>
  <li>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(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0026.html">Blair
    Dillaway</a>)] The SOAP 1.1. binding MUST support SOAP 1.1, modified to
    use the W3C XML Schema definitions [<a href="#ref-soap-schemas">SOAP
    Schemas</a>].</li>
  <li>The specification MUST define how to convey application context in
    requests/responses, e.g. transaction amount, arbitrary XML {Microsoft,
    Sun}</li>
  <li>All formats SHOULD permit application/trust server extension through
    the use of additional elements in another namespace.</li>
  <li>The specification MUST define a unified request/response mechanism
    across services (Locate, Validate etc.), including uniform error
    responses, query and response formats.</li>
  <li>The specification MUST permit opaque data to be associated with a
    request and returned with the corresponding response.</li>
  <li>The specification MUST define which requests are idempotent (can repeat
    without ill effect), and which are not.</li>
  <li>The specification MUST define a protocol which provides the means to
    match requests and responses.</li>
  <li>A client SHOULD be able to control the number of key bindings in a
    response returned (e.g. specify the maximum to be returned).</li>
  <li>The specification MUST use schema typing and namespace support for the
    &lt;Respond&gt; element in &lt;Locate&gt; and &lt;Validate&gt;  responses
    (rather than strings). {Reagle}, [<a
    href="#ref-XKMSWorkshopMinutes">WorkshopMeeting</a>]</li>
  <li>A Validate request MAY also include values to be Located and returned
    in the response.</li>
  <li>The specification MUST allow the server to return a subset or superset
    of the elements requested by the clients. {Reagle} [<a
    href="#ref-XKMSWorkshopMinutes">WorkshopMeeting</a>]. Security
    implications MUST be discussed in the Security Concerns section of the
    specification.</li>
  <li>The specification SHOULD define a mechanism so that responses include
    both a list of valid key bindings, and a list of invalid key bindings,
    removing the ambiguity possible with valid, invalid and indeterminate key
    binding status possibilities combined with a single type of response.
    {Salz} [XKMS developers list]</li>
</ol>

<h3><a id="sec-Objects" name="sec-Objects"></a>2.5. Objects and
Processing</h3>
<ol>
  <li>The specification SHOULD define how to register a key for specific uses
    and how to update the allowed uses over time. [<a
    href="#XKMSPositionPapers">XKMSPositionPapers</a> ]</li>
  <li>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 &lt;Purpose&gt; subtype for the &lt;KeyUsage&gt; element.</li>
  <li>Key bindings MUST have issuers associated with them.</li>
  <li>The following KeyInfo formats MUST be supported: KeyName, KeyValue,
    RetrievalMethod and MgmtData.<br />
    The following KeyInfo formats MUST be supported by a trust server if the
    service claims interoperability with PX509: X509Cert, X509Chain and
    X509CRL. X509Chain MUST be defined in the XKMS specifications. The other
    KeyInfo formats are defined in the XML Signature recommendation.<br />
    The XKMS registration Private format which MUST be supported if the
    service supports either service generated key pairs or key recovery.
    [List(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0023.html">Sébastien
    Pouliot)</a>]</li>
  <li>Exclusive Canonicalization [<a
    href="#ref-exclusive">ExclusiveCanonicalization</a>] 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.</li>
  <li>XML Key Management applications MUST be XML-namespaces [<a
    href="#ref-XML-ns">XML-namespaces</a>] aware.</li>
  <li>XML Key Management applications MUST be XML Schema [<a
    href="#ref-XML-schema">XML-schema</a>] aware in that they create XML Key
    Management instances conforming to the key management schema definitions.
    {Reagle} Schema validation is not required.</li>
  <li>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.</li>
  <li>The specification SHOULD be compatible with the use of authentication
    mechanisms carried in SOAP/XML Protocol messages and/or the transport
    protocol. XKMS SHOULD not define any new authentication mechanism beyond
    key proof of possession.</li>
  <li>The specification MUST describe how to provide proof of possession of
    private keys.</li>
  <li>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.</li>
</ol>

<h2><a id="sec-scope" name="sec-scope"></a>3. Out of Scope</h2>
These items are out of scope (at least for the initial specifications
produced by the working group). In some cases an in-scope requirement (e.g.
the ability to use XKMS in the context of the 4 corner model) may imply some
of this functionality, but that does not mean the XKMS specification is
required to define that functionality.
<ol>
  <li>Design of new cryptographic algorithms.</li>
  <li>Issues of non-repudiation, including but not limited to 'technical
    non-repudiation' and 'contractual non-repudiation'.</li>
  <li>Sources of trusted time.</li>
  <li>Models and data structures for establishing inter-domain trust,
    including but not limited to 'cross-certification'.</li>
  <li>Expression of existing PKI data structures in XML.</li>
  <li>Specification of inter-domain trust semantics.</li>
  <li>Authorization issues and more specifically authorization assertions
    (e.g. SAML).</li>
  <li>Attribute certificates.</li>
  <li>Knowledge representation syntax.</li>
  <li>Audit management.</li>
  <li>Establishment of trust server key authority delegation. 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 (<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0017.html">Stephen
    Farrell</a>)]</li>
  <li>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(<a
    href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0026.html">Blair
    Dillaway</a>)]</li>
  <li>Issues of anonymous access and service use are not the primary focus of
    the work, but may be supported.</li>
  <li>Private key retrieval services that extend beyond the return of a
    service-generated private key as part of registration (e.g. Roaming).</li>
  <li>Server chaining and referral mechanisms.</li>
  <li>XML Key Management of symmetric keys.</li>
  <li>Caching support.</li>
</ol>

<h2><a name="sec-Coordination" id="sec-Coordination"></a>4 Coordination</h2>
Coordination with other groups is as specified in the Charter [<a
href="#XKMSCharter">Charter</a>].

<h2><a name="sec-IPR" id="sec-IPR"></a>5 Intellectual Property</h2>
Intellectual property issues are as in the Charter [<a
href="#XKMSCharter">Charter</a>].

<h2><a name="sec-References" id="sec-References"></a>6 References</h2>
<dl>
  <dt><a name="ref-DOM" id="ref-DOM"></a>DOM</dt>
    <dd><a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html">Document
      Object Model Core, Level 3</a>. Arnaud Le Hors. W3C Working Draft.
      January 2001.<br />
      <a
      href="http://www.w3.org/TR/DOM-Level-3-Core/core.html">http://www.w3.org/TR/DOM-Level-3-Core/core.html</a></dd>
  <dt><a id="ref-exclusive" name="ref-exclusive"></a>Exclusive
  Canonicalization - work in progress</dt>
    <dd><a
      href="http://www.w3.org/Signature/Drafts/xml-exc-c14n.html">http://www.w3.org/Signature/Drafts/xml-exc-c14n.html</a></dd>
  <dt><a name="ref-MIME" id="ref-MIME"></a>MIME</dt>
    <dd>RFC2046. MIME Part Two: Media Types  November 1996.</dd>
    <dd><a
      href="http://www.ietf.org/rfc/rfc2046.txt">http://www.ietf.org/rfc/rfc2046.txt</a></dd>
  <dt><a id="ref-p3p" name="ref-p3p"></a>P3P Working Draft</dt>
    <dd><a href="http://www.w3.org/TR/P3P/">http://www.w3.org/TR/P3P/</a></dd>
  <dt><a id="ref-rfc-2119" name="ref-rfc-2119"></a>RFC 2119</dt>
    <dd>"Key words for use in RFCs to Indicate Requirement Levels", S.
      Bradner, March 1997, RFC 2119, <a
      href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></dd>
  <dt><a id="ref-rfc-2459" name="ref-rfc-2459"></a>RFC 2459</dt>
    <dd>"Internet X.509 Public Key Infrastructure Certificate and CRL
      Profile",R. Housley, W. Ford, W. Polk, D. Solo, January 1999, RFC 2459
      <a
      href="http://www.ietf.org/rfc/rfc2459.txt">http://www.ietf.org/rfc/rfc2459.txt</a></dd>
  <dt><a id="ref-saml" name="ref-saml"></a>SAML</dt>
    <dd>Security Assertion Markup Language (SAML), <a
      href="http://www.oasis-open.org/committees/security/docs/">http://www.oasis-open.org/committees/security/docs/</a></dd>
  <dt><a id="ref-soap" name="ref-soap"></a>SOAP</dt>
    <dd>Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, <a
      href="http://www.w3.org/TR/SOAP/">http://www.w3.org/TR/SOAP/</a></dd>
  <dt><a id="ref-soap-schemas" name="ref-soap-schemas"></a>SOAP Schemas</dt>
    <dd><a
      href="http://schemas.xmlsoap.org/soap/encoding/">http://schemas.xmlsoap.org/soap/encoding/</a>
      and <a
      href="http://schemas.xmlsoap.org/soap/envelope/">http://schemas.xmlsoap.org/soap/envelope/</a></dd>
  <dt><a id="ref-tls" name="ref-tls"></a>TLS</dt>
    <dd>The TLS Protocol, Version 1.0, RFC 2246, T. Dierks, C. Allen, <a
      href="http://www.ietf.org/rfc/rfc2246.txt">http://www.ietf.org/rfc/rfc2246.txt</a></dd>
  <dt><a id="refxkmschange" name="refxkmschange"></a>XKMS Change Proposal</dt>
    <dd class="nov7"><a
      href="http://www.xmltrustcenter.org/xkms/docs/xkms_change_proposal.html">http://www.xmltrustcenter.org/xkms/docs/xkms_change_proposal.html</a></dd>
  <dt><a id="XKMSCharter" name="XKMSCharter"></a>XKMS Charter</dt>
    <dd><a
      href="http://www.w3.org/2001/XKMS/2001/01/xkms-charter.html">http://www.w3.org/2001/XKMS/2001/01/xkms-charter.html</a></dd>
  <dt><a id="ref-xkmsWorkshopMailList"
  name="ref-xkmsWorkshopMailList"></a>Mailing Lists</dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/www-xkms-ws/">http://lists.w3.org/Archives/Public/www-xkms-ws/</a></dd>
    <dd><a
      href="http://lists.w3.org/Archives/Public/www-xkms/">http://lists.w3.org/Archives/Public/www-xkms/</a></dd>
  <dt><a id="XKMSProposal" name="XKMSProposal"></a>XKMS-Proposal</dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Aug/att-0048/02-xkms-activity.html">http://lists.w3.org/Archives/Public/www-xkms-ws/2001Aug/att-0048/02-xkms-activity.html</a></dd>
  <dt><a id="ref-xkms-note" name="ref-xkms-note"></a>XKMS 1.1 W3C Note</dt>
    <dd class="nov7"><a
      href="http://www.w3.org/TR/xkms/">http://www.w3.org/TR/xkms/</a></dd>
  <dt><a id="ref-XKMSWorkshopMinutes" name="ref-XKMSWorkshopMinutes"></a>XKMS
  Workshop Meeting Minutes</dt>
    <dd><a
      href="http://www.w3.org/2001/07/xkms-ws/minutes.html">http://www.w3.org/2001/07/xkms-ws/minutes.html</a></dd>
  <dt><a id="XKMSPositionPapers" name="XKMSPositionPapers"></a>XKMS Workshop
  Position Papers</dt>
    <dd><a
      href="http://www.w3.org/2001/07/xkms-ws/positions/">http://www.w3.org/2001/07/XKMS-Ws/positions/</a></dd>
  <dt><a id="ref-xkmsRequirementsTeleCon"
  name="ref-xkmsRequirementsTeleCon"></a>Meetings</dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0028.html">http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0028.html</a></dd>
    <dd><a
      href="http://www.w3.org/2001/XKMS/Minutes/011114-tele.html">http://www.w3.org/2001/XKMS/Minutes/011114-tele.html</a></dd>
    <dd><a
      href="http://www.w3.org/2001/XKMS/Minutes/011209-slc/011209-slc-f2f1.html">http://www.w3.org/2001/XKMS/Minutes/011209-slc/011209-slc-f2f1.html</a></dd>
    <dd><a
      href="http://www.w3.org/2001/XKMS/Minutes/020123-tele.html">http://www.w3.org/2001/XKMS/Minutes/020123-tele.html</a></dd>
  <dt><a name="ref-XML" id="ref-XML"></a>XML</dt>
    <dd>Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J.
      Paoli, C. M. Sperberg-McQueen. February 1998.</dd>
    <dd><a
      href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/1998/REC-xml-19980210</a></dd>
  <dt><a name="ref-XML-C14N" id="ref-XML-C14N"></a>XML-C14N</dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical
      XML.</a> W3C Recommendation. J. Boyer. March 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a><br
      />
      <a
      href="http://www.ietf.org/rfc/rfc3076.txt">http://www.ietf.org/rfc/rfc3076.txt</a></dd>
  <dt><a name="ref-xml-dsig" id="ref-xml-dsig"></a>XMLDSIG</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">XML-Signature
      Syntax and Processing</a>. W3C Proposed Recommendation. D. Eastlake, J.
      Reagle, and D. Solo. August 2001. (<a
      href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/</a>)</dd>
    <dd><a href="http://www.w3.org/TR/xmldsig-requirements">XML Signature
      Requirements</a>. W3C Working Draft. J. Reagle. October 1999. (<a
      href="http://www.w3.org/TR/xmldsig-requirements">http://www.w3.org/TR/xmldsig-requirements</a>
      )</dd>
  <dt><a id="ref-xml-encryption" name="ref-xml-encryption"></a>XML
  Encryption</dt>
    <dd><a href="http://www.w3.org/TR/xmlenc-core/">XML Encryption Syntax and
      Processing</a>. W3C Working Draft. T. Imamura, B. Dillaway, J. Schaad,
      E. Simon. October 2001. (<a
      href="http://www.w3.org/TR/xmlenc-core/">http://www.w3.org/TR/xmlenc-core/</a>)</dd>
    <dd><a href="http://www.w3.org/TR/xml-encryption-req">XML Encryption
      Requirements</a>. W3C Working Draft. J. Reagle. October 2001. (<a
      href="http://www.w3.org/TR/xml-encryption-req">http://www.w3.org/TR/xml-encryption-req</a>)</dd>
  <dt><a name="ref-XML-ns" id="ref-XML-ns"></a>XML-ns</dt>
    <dd>Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman.
      January 1999.</dd>
    <dd><a
      href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a></dd>
  <dt><a id="XMLprotocol" name="XMLprotocol"></a>XML Protocol</dt>
    <dd><a
    href="http://www.w3.org/2002/ws/">http://www.w3.org/2002/ws/</a></dd>
  <dt><a name="ref-XML-schema" id="ref-XML-schema"></a>XML-schema</dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML
      Schema Part 1: Structures</a> W3C Recommendation. D. Beech, M. Maloney,
      N. Mendelsohn, H. Thompson. May 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a><br
      />
      <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML
      Schema Part 2: Datatypes</a> W3C Recommendation. P. Biron, A. Malhotra.
      May 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a></dd>
  <dt><a name="ref-URI" id="ref-URI"></a>URI</dt>
    <dd>RFC2396. <em>Uniform Resource Identifiers (URI): Generic Syntax.</em>
      T. Berners-Lee, R. Fielding, L. Masinter. August 1998<br />
      <a
      href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a></dd>
</dl>
</body>
</html>