index.html 67 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">
<head>
  <title>XML Key Management Specification (XKMS) Bindings</title>
  <meta name="ProgId" content="FrontPage.Editor.Document" />
  <style type="text/css">
      <!-- /*<![CDATA[*/
p.Code       { font-size: 9pt; background-color: #00ffa7; background-repeat: repeat;
               background-attachment: scroll; font-family: Courier;
               margin-left: 0.5in; margin-right: 0.5in; margin-top: 0in;
               margin-bottom: 0pt }
a.markParagraph { font-size: 8pt }
p.toc1       { text-align: left; font-size: 14pt; margin-left: 1pt; margin-top: 6pt;
               margin-bottom: 1pt }
p.toc2       { line-height: 100%; font-size: 12pt; margin-top: 4pt; margin-bottom: 0pt }
p.toc3       { line-height: 100%; margin-top: 2pt; margin-bottom: 10pt }
span.ID      { font-family: Courier }
pre.Code     { font-size: 9pt; background-color: #ffffa7; background-repeat: repeat;
               background-attachment: scroll; font-family: Courier;
               margin-left: 0in; margin-right: 0in; margin-top: 0in;
               margin-bottom: 0pt }
pre.Example  { font-size: 9pt; background-color: #d2e9ff; background-repeat: repeat;
               background-attachment: scroll; font-family: Courier;
               margin-left: 0.5in; margin-right: 0.5in; margin-top: 0in;
               margin-bottom: 0pt }
p.Comment    { font-size: 8pt; color: #d2e9ff; background-repeat: repeat;
               background-attachment: scroll; font-family: Courier; color:
               #0000FF; font-style: italic; margin-left: 0.5in; margin-right:
               0.5in; margin-top: 0in; margin-bottom: 0pt }
th.ID        { font-family: Courier }
td.ID     { font-family: Courier }
c2      { font-family: Courier }
p.center     { text-align: center }
p.caption    { text-align: center }
p.warning    { font-weight: bold }
table        {  }
h1.appendix  { page-break-before: always }
div.center   { text-align: center }
:link        { color: #0000FF }
:visited     { color: #800080 }
span.c32     { background-color: #FFFF00 }
span.c25     { color: red }
span.c13     { font-family: Arial }
span.c12     { font-weight: 400 }
/*]]>*/ -->


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

<body xml:lang="EN-US" lang="EN-US">

<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 class="NoNumber" id="title"><a name="__Section_Marker_1"></a>XML Key
Management Specification (XKMS) Bindings</h1>

<h2 class="NoNumber" id="version"><a name="__Section_Marker_2"></a>Version
2.0</h2>

<h2 class="NoNumber" id="W3C-doctype"><a name="__Section_Marker_3"></a> <a
name="Masthead" id="Masthead">W3C Working Draft 18 April 2003</a></h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/">http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/xkms2-bindings/">http://www.w3.org/TR/xkms2-bindings/</a>&nbsp;</dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/WD-xkms2-20020318/">http://www.w3.org/TR/2002/WD-xkms2-20020318/</a></dd>
  <dt>Editor:</dt>
    <dd><a href="mailto:pbaker@verisign.com">Phillip Hallam-Baker</a>
    VeriSign</dd>
  <dt>Contributors:</dt>
    <dd>See the <a href="#Acknowledgments">Acknowledgments</a>.</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 2003 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.ercim.org/"><abbr
title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p>
<hr title="Separator from Header" />
</div>

<div>
<h2 class="Abstract"><a name="__Section_Marker_4"
id="__Section_Marker_4"></a> <a id="abstract"
name="abstract">Abstract</a></h2>

<p><a name="__Paragraph_2" id="__Paragraph_2"
class="markParagraph">[2]</a>This document specifies protocol bindings with
security characteristics for the <a href="http://www.w3.org/TR/xkms2/">XML
Key Management Specification (XKMS</a>).</p>

<h2 class="NoNumber"><a name="__Section_Marker_5"
id="__Section_Marker_5"></a> <a name="status" id="status">Status of this
document</a></h2>

<p><a name="__Paragraph_3" id="__Paragraph_3"
class="markParagraph">[3]</a>This is a Last Call for the "XML Key Management
Specification Bindings" as <a
href="http://lists.w3.org/Archives/Public/www-xkms/2003Apr/0022.html">agreed
to</a> by the <a href="http://www.w3c.org/2001/XKMS/">XKMS Working
Group</a> (<a href="http://www.w3.org/2001/XKMS/Activity.html">Activity
Statement</a>). The Last Call review period ends in 5 weeks on <em>23 May
2003</em>.</p>

<p><a name="__Paragraph_4" id="__Paragraph_4"
class="markParagraph">[4]</a>Please send comments to the editor (&lt;<a
href="mailto:pbaker@verisign.com">pbaker@verisign.com</a>&gt;) and cc: the
working group mailing list <a
href="mailto:www-xkms@w3.org">www-xkms@w3.org</a> (<a
href="http://lists.w3.org/Archives/Public/www-xkms/">archive</a>)</p>

<p><a name="__Paragraph_5" id="__Paragraph_5"
class="markParagraph">[5]</a>The Working Group will try to <a
href="http://www.w3.org/1999/10/nsuri">use a new namespace</a> when changes
in its syntax or processing are substantive. However, this namespace might be
reused (prior to reaching Candidate Recommendation) by subsequent drafts in
such a way as to cause instances using the namespace to become invalid or to
change in meaning or affect the operation of existing software. Requests for
a more stringent level of namespace stability should be made to the Working
Group.</p>

<p><a name="__Paragraph_6" id="__Paragraph_6"
class="markParagraph">[6]</a>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><a name="__Paragraph_7" id="__Paragraph_7"
class="markParagraph">[7]</a>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.</p>
</div>

<h2 class="TableOfContents"><a name="__Section_Marker_6"
id="__Section_Marker_6"></a> <a name="TableOfContents"
id="TableOfContents">Table Of Contents</a></h2>

<p class="toc1"><a href="#__Section_Marker_1">XML Key Management
Specification (XKMS) Bindings</a></p>

<p class="toc2"><a href="#__Section_Marker_2">Version 2.0</a></p>

<p class="toc2"><a href="#__Section_Marker_3">W3C Working Draft 18 April
2003</a></p>

<p class="toc2"><a href="#__Section_Marker_4">Abstract</a></p>

<p class="toc2"><a href="#__Section_Marker_5">Status of this document</a></p>

<p class="toc2"><a href="#__Section_Marker_6">Table Of Contents</a></p>

<p class="toc1"><a href="#__Section_1">1 Introduction</a></p>

<p class="toc2"><a href="#__Section_1_1">1.1 Editorial and Conformance
Conventions</a></p>

<p class="toc2"><a href="#__Section_1_2">1.2 Acknowledgments</a></p>

<p class="toc2"><a href="#__Section_1_3">1.3 Definition of Terms</a></p>

<p class="toc2"><a href="#__Section_1_4">1.4 Structure of this
documentt</a></p>

<p class="toc1"><a href="#__Section_2">2 Security Requirements</a></p>

<p class="toc2"><a href="#__Section_2_1">2.1 Confidentiality</a></p>

<p class="toc2"><a href="#__Section_2_2">2.2 Request Authentication</a></p>

<p class="toc2"><a href="#__Section_2_3">2.3 Response Authentication</a></p>

<p class="toc2"><a href="#__Section_2_4">2.4 Persistent Authentication</a></p>

<p class="toc2"><a href="#__Section_2_5">2.5 Message Correlation (Response
Replay and Request Substitution)</a></p>

<p class="toc2"><a href="#__Section_2_6">2.6 Request Replay</a></p>

<p class="toc2"><a href="#__Section_2_7">2.7 Denial of Service</a></p>

<p class="toc2"><a href="#__Section_2_8">2.8 Security Requirements
Summary</a></p>

<p class="toc1"><a href="#__Section_3">3 SOAP Binding</a></p>

<p class="toc2"><a href="#__Section_3_1">3.1 XKMS SOAP Message Binding</a></p>

<p class="toc2"><a href="#__Section_3_2">3.2 Namespace inclusions</a></p>

<p class="toc2"><a href="#__Section_3_3">3.3 Computation of XML Signature
Elements in XKMS Messages</a></p>

<p class="toc2"><a href="#__Section_3_4">3.4 Use of SOAP Faults</a></p>

<p class="toc2"><a href="#__Section_3_5">3.5 SOAP over HTTP binding</a></p>

<p class="toc1"><a href="#__Section_4">4 Security Bindings</a></p>

<p class="toc2"><a href="#__Section_4_1">4.1 Payload Authentication
Binding</a></p>

<p class="toc2"><a href="#__Section_4_2">4.2 Secure Socket Layer and
Transaction Layer (SSL/TLS)Security Binding</a></p>

<p class="toc1"><a href="#__Section_Appendix_A">Appendix A References</a></p>
<hr title="Separator from Header" />

<h1><a name="__Section_1" id="__Section_1">1</a> <a name="Introduction"
id="Introduction">Introduction</a></h1>

<h2><a name="__Section_1_1" id="__Section_1_1">1.1</a> <a id="sec-Editorial"
name="sec-Editorial">Editorial</a> and Conformance Conventions</h2>

<p><a name="__Paragraph_8" id="__Paragraph_8"
class="markParagraph">[8]</a>This specification uses XML Schemas [<a
href="#XML-Schema1">XML-schema</a>]
to describe the content model.</p>

<p><a name="__Paragraph_9" id="__Paragraph_9"
class="markParagraph">[9]</a>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this specification are to be interpreted as described in <a
href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a> [<a
href="#ref-KEYWORDS">KEYWORDS</a>]:</p>

<blockquote>
  <p><a name="__Paragraph_10" id="__Paragraph_10"
  class="markParagraph">[10]</a>"they MUST only be used where it is actually
  required for interoperation or to limit behavior which has potential for
  causing harm (e.g., limiting retransmissions)"</p>
</blockquote>

<p><a name="__Paragraph_11" id="__Paragraph_11"
class="markParagraph">[11]</a>Consequently, we use these capitalized keywords
to unambiguously specify requirements over protocol and application features
and behavior that affect the interoperability and security of
implementations. These key words are not used (capitalized) to describe XML
grammar; schema definitions unambiguously describe such requirements and we
wish to reserve the prominence of these terms for the natural language
descriptions of protocols and features. For instance, an XML attribute might
be described as being "optional." Compliance with the XML-namespace
specification [<a href="#ref-XML-NS">XML-NS</a>] is described as
"REQUIRED."</p>

<h2><a name="__Section_1_2" id="__Section_1_2">1.2</a> <a
name="Acknowledgments" id="Acknowledgments">Acknowledgments</a></h2>

<p><a name="__Paragraph_12" id="__Paragraph_12"
class="markParagraph">[12]</a>The contributions of the following Working
Group members to this specification are gratefully acknowledged in accordance
with the <a href="http://www.w3.org/2001/XKMS/Contributor.html">contributor
policies</a> and the active <a
href="http://www.w3.org/2001/XKMS/Participants.html">WG roster</a>.</p>
<ul>
  <li>Daniel Ash, Identrus</li>
  <li>Blair Dillaway, Microsoft</li>
  <li>Donald Eastlake 3rd, Motorola</li>
  <li>Yassir Elley, Sun Microsystems</li>
  <li>Jeremy Epstein, webMethods</li>
  <li>Stephen Farrell, Baltimoree<span class="731370520-26032003"><font
    face="Arial">(Co-Chair)</font></span></li>
  <li>Phillip Hallam-Baker, VeriSign Inc. (Editor)</li>
  <li>Loren Hart, VeriSign Inc.</li>
  <li>Mack Hicks, Bank of America</li>
  <li>Merlin Hughes, Baltimore</li>
  <li>Frederick Hirsch, Nokia Mobile Phones</li>
  <li>Mike Just, Treasury Board of Canada Secretariat</li>
  <li>Brian LaMacchia, Microsoft</li>
  <li>Pradeep Lamsal</li>
  <li>Shivaram Mysore, Sun Microsystems <span
    class="731370520-26032003"><font
  face="Arial">(Co-Chair)</font></span></li>
  <li>Joseph Reagle, W3C</li>
  <li>Dave Remy, GeoTrust, Inc.</li>
  <li>Peter Rostin, RSA Security Inc.</li>
  <li>Ed Simon, XMLsec Inc.</li>
  <li>Slava Galperin,&nbsp; Sun Microsystems</li>
</ul>

<p><a name="__Paragraph_13" id="__Paragraph_13"
class="markParagraph">[13]</a>The authors also acknowledge the extensive
assistance provided in the design stage of this specification by David Solo
(CitiGroup), and the contributions of Jeremy Epstein, (webMethods), Andrew
Layman&nbsp; (Microsoft), Dr Paul Boisen (NSA),&nbsp; Dan Guinan, Marc Hayes,
Alex Deacon, Mingliang Pei (VeriSign).</p>

<h2><a name="__Section_1_3" id="__Section_1_3">1.3</a> <a
name="DefinitionofTerms" id="DefinitionofTerms">Definition of Terms</a></h2>

<p><a name="__Paragraph_14" id="__Paragraph_14"
class="markParagraph">[14]</a>This document uses the terms defined in section
1.3 of part one of this specification in the manner described therin.</p>

<h2><a name="__Section_1_4" id="__Section_1_4">1.4</a> <a
name="Structureofthisdocument" id="Structureofthisdocument">Structure of this
Document</a></h2>

<p><a name="__Paragraph_15" id="__Paragraph_15"
class="markParagraph">[15]</a>The remainder of this document describes the
XML Key Information Service Specification and XML Key Registration Service
Specification.</p>
<dl>
  <dt><b>Section 2</b>: Security Requirements</dt>
    <dd>The security requirements of the XKMS protocol are specified.</dd>
  <dt>Section 3: Payload Security Protocol</dt>
    <dd>The security properties supported by the XKMS payload security
      features are described.</dd>
  <dt>Section 4: Security Bindings</dt>
    <dd>The use of XKMS payload security features is described in the context
      of specific security protocols.</dd>
  <dt>Section 5: Security Considerations</dt>
    <dd>Security considerations relevant to the implementation and deployment
      of the specification are discussed.</dd>
</dl>

<h1><a name="__Section_2" id="__Section_2">2</a> <a
name="SecurityRequirements" id="SecurityRequirements">Security
Requirements</a></h1>

<p><a name="__Paragraph_16" id="__Paragraph_16"
class="markParagraph">[16]</a>Security enhancements MAY be required to
control the following risks:</p>
<ul>
  <li>Confidentiality</li>
  <li>Request Authentication</li>
  <li>Response Authentication</li>
  <li>Persistent Authentication</li>
  <li>Response Replay</li>
  <li>Request Substitution</li>
  <li>Request Replay</li>
  <li>Denial of Service</li>
</ul>

<p><a name="__Paragraph_17" id="__Paragraph_17"
class="markParagraph">[17]</a>The security enhancements required varies
according to the application. In the case of a free or un-metered service the
service may not require authentication of the request. A responder that
requires an authenticated request must know in that circumstance that the
request corresponds to the specified response.</p>

<h2><a name="__Section_2_1" id="__Section_2_1">2.1</a> <a
name="Confidentiality" id="Confidentiality">Confidentiality</a></h2>

<p><a name="__Paragraph_18" id="__Paragraph_18"
class="markParagraph">[18]</a>Message confidentiality protects protocol
messages from disclosure to third parties. Confidentiality MAY be a
requirement for an XKMS service. Deployments SHOULD consider the extent to
which the content of XKMS messages reveal sensitive information. A
confidentiality requirement MAY exist even if a service only provides
information from public sources as the contents of a request might disclose
information about the client.</p>

<p><a name="__Paragraph_19" id="__Paragraph_19"
class="markParagraph">[19]</a>The use of transport or payload confidentiality
protection is NOT a substitute for the encryption of private keys specified
in the XKRSS Registration and Recovery services. A service that supports
registration of server generated keys or Key Recovery MUST implement the use
of XML Encryption with a strong cipher.</p>

<p><a name="__Paragraph_20" id="__Paragraph_20"
class="markParagraph">[20]</a>An XKMS service SHOULD support Confidentiality
by means of encryption.</p>

<p><a name="__Paragraph_21" id="__Paragraph_21"
class="markParagraph">[21]</a>The means by which the client determines that
the encryption key of the service is trustworthy is outside the scope of this
specification. Possible mechanisms include:</p>
<ul type="disc">
  <li>A root key embedded in the client application</li>
  <li>A trustworthy signing key exchanged using an XML based assertion
    mechanism such as that proposed by <span
    style="background-position: 0% 0%"><a
    href="#WSTrustAxiom">WS-TrustAxiom</a></span>..</li>
  <li>A signing key obtained using some other retrieval mechanism such as <a
    href="#PKIX">PKIX</a> or <a href="#SPKI">SPKI</a>.</li>
</ul>

<p><a name="__Paragraph_22" id="__Paragraph_22"
class="markParagraph">[22]</a>An XKMS service MAY determine the
trustworthiness of an encryption key by reference to another XKMS service
provided that the chain of references is eventually grounded by a mechanism
that establishes direct trust between the client and the service.</p>

<h2><a name="__Section_2_2" id="__Section_2_2">2.2</a> <a
name="RequestAuthentication" id="RequestAuthentication">Request
Authentication</a></h2>

<p><a name="__Paragraph_23" id="__Paragraph_23"
class="markParagraph">[23]</a>Request Message Authentication MAY be required.
An XKMS Service MAY require request authentication in deployments where the
XKMS service is restricted to a specific audience, possibly as a paid
service. An XKMS Service MAY require request authentication in contexts where
different levels of service are supported according to the identity of the
requestor.</p>

<p><a name="__Paragraph_24" id="__Paragraph_24"
class="markParagraph">[24]</a>In addition various forms of Authentication MAY
be required in the XKRSS Registration protocol to confirm the credentials of
the party initiating the request and their possession of the private key
component of the key pair(s) being registered.</p>

<p><a name="__Paragraph_25" id="__Paragraph_25"
class="markParagraph">[25]</a>An XKMS service SHOULD support Message Request
Authentication.</p>

<h2><a name="__Section_2_3" id="__Section_2_3">2.3</a> <a
name="ResponseAuthentication" id="ResponseAuthentication">Response
Authentication</a></h2>

<p><a name="__Paragraph_26" id="__Paragraph_26"
class="markParagraph">[26]</a>Message Response Authentication MAY be
required. Message Response Authentication is required in any deployment of a
Validate service. A Locate service that provides only data that is
self-authenticating such as X.509 or PGP certificates does not require
Message Response Authentication.</p>

<p><a name="__Paragraph_27" id="__Paragraph_27"
class="markParagraph">[27]</a>Note that Message Response Authentication is
considered separately from Response Replay Protection.</p>

<p><a name="__Paragraph_28" id="__Paragraph_28"
class="markParagraph">[28]</a>An XKMS service SHOULD support Request
Authentication.</p>

<h2><a name="__Section_2_4" id="__Section_2_4">2.4</a> <a
name="PersistentAuthentication" id="PersistentAuthentication">Persistent
Authentication</a></h2>

<p><a name="__Paragraph_29" id="__Paragraph_29"
class="markParagraph">[29]</a>In some circumstances requests or responses or
to both may require persistent authentication. That is a message sent by A
and authenticated by B may be subject to forwarding and authentication by C.
In addition some applications may require further measures to ensure that
messages meet certain legal standards to prevent repudiation.</p>

<p><a name="__Paragraph_30" id="__Paragraph_30"
class="markParagraph">[30]</a>An XKMS service MAY support Persistent
Authentication by means of a digital signature on the message.</p>

<h2><a name="__Section_2_5" id="__Section_2_5">2.5</a> <a
name="MessageCorrelation" id="MessageCorrelation">Message Correlation</a>
(Response Replay and Request Substitution)</h2>

<p><a name="__Paragraph_31" id="__Paragraph_31"
class="markParagraph">[31]</a>An XKMS service MUST support a means of
ensuring correct message correlation. That is the requestor must be assured
that the response returned was made in response to the intended request sent
to the service and not a modification of that request (Request Substitution
attack) or a response to an earlier request (response replay attack).</p>

<p><a name="__Paragraph_32" id="__Paragraph_32"
class="markParagraph">[32]</a>In order to prevent response replay and request
message substitution attacks the requestor SHOULD ensure that the response
corresponds to the request. For correspondence verification to be possible
authentication of the response is required. In the TLS binding the
correspondence between the request and response is provided by the transport
layer. For message layer security mechanisms such as payload security the
mechanism required depends on whether or not the request is authenticated as
follows:</p>
<dl>
  <dt>Authenticated Request</dt>
    <dd>If the request and the response are authenticated the correspondence
      of the request and response may be determined by verifying the value of
      RequestID in the response.</dd>
  <dt>Digest Authenticated Request</dt>
    <dd>If the original request was authenticated by means of an XML
      Signature with a message digest as the signing algorithm, the service
      can still ensure a strong binding of the response to the original
      request by means of the &lt;RequestSignatureValue&gt; element.</dd>
</dl>

<h2><a name="__Section_2_6" id="__Section_2_6">2.6</a> <a
name="RequestReplay" id="RequestReplay">Request Replay</a></h2>

<p><a name="__Paragraph_33" id="__Paragraph_33"
class="markParagraph">[33]</a>An XKMS service may require protection against
a Request replay attack. In circumstances where no accounting or other
auditing is used to keep track of requests made, protection against a request
replay attack may not be required.</p>

<p><a name="__Paragraph_34" id="__Paragraph_34"
class="markParagraph">[34]</a>An XKMS service MAY provide protection against
a Request Replay.</p>

<h2><a name="__Section_2_7" id="__Section_2_7">2.7</a> <a
name="DenialofService" id="DenialofService">Denial of Service</a></h2>

<p><a name="__Paragraph_35" id="__Paragraph_35"
class="markParagraph">[35]</a>An XKMS service may require protection against
a Denial of Service attack by means of protocol measures. Such measures may
not be required in circumstances where an XKMS service is protected against
Denial of Service by other means such as the service is managed on an
isolated, tightly controlled network and does not provide service outside
that network.</p>

<p><a name="__Paragraph_36" id="__Paragraph_36"
class="markParagraph">[36]</a>Denial of service attacks that originate from a
single identified source or set of sources may be addressed by applying
velocity controls. In cases where the source of the denial of service is
disguised lightweight authentication techniques such as the two-phase
protocol described bellow may be used to detect requests from forged
addresses.</p>

<p><a name="__Paragraph_37" id="__Paragraph_37"
class="markParagraph">[37]</a>An XKMS service SHOULD support protection
against a Denial of Service attack.</p>

<h2><a name="__Section_2_8" id="__Section_2_8">2.8</a> <a
name="SecurityRequirementsSummary" id="SecurityRequirementsSummary">Security
Requirements Summary</a></h2>

<p><a name="__Paragraph_38" id="__Paragraph_38"
class="markParagraph">[38]</a>The following table summarizes the possible
security requirements that an XKMS service deployment may be subject to:</p>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%">
  <tbody>
    <tr>
      <th width="30%" height="19">Security Issue</th>
      <th width="15%" height="19">Requirement</th>
      <th height="19">Comments</th>
    </tr>
    <tr>
      <td valign="top" width="30%" height="72">Confidentiality</td>
      <td width="15%" valign="top" align="center" height="72">Some</td>
      <td valign="top" height="72">The information provided by an XKMS
        service may be confidential, the fact that a party has requested
        particular information from an XKMS service may allow confidential
        information to be deduced. Many XKMS applications do not require
        confidentiality however.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="54">Request Authentication</td>
      <td width="15%" valign="top" align="center" height="54">Some</td>
      <td valign="top" height="54">A service only needs to authenticate a
        request for information if either the information is confidential or
        some form of charge is to be made for use of the service.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="36">Response Authentication</td>
      <td width="15%" valign="top" align="center" height="36">Most</td>
      <td valign="top" height="36">An XKMS service that provides only a
        Location service for self authenticating key information such as
        Digital Certificates does not require authentication.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="54">Persistent Authentication</td>
      <td width="15%" valign="top" align="center" height="54">Some</td>
      <td valign="top" height="54">Although some XKMS applications have a
        specific requirement to support Non-Repudiation, the ability to
        repudiate requests and responses is acceptable in many
      applications.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="54">Message Correspondence</td>
      <td width="15%" valign="top" align="center" height="54">All</td>
      <td valign="top" height="54">The RequestID correspondence mechanism can
        only be used if the Request Authentication mechanism can be relied
        upon. Otherwise the Digest Mechanism should be used.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="36">Request Replayy</td>
      <td width="15%" valign="top" align="center" height="36">Some</td>
      <td valign="top" height="36">Request replay attacks are likely to only
        be a concern if the service charges on a per request basis or as a
        type of Denial of Service attack.</td>
    </tr>
    <tr>
      <td valign="top" width="30%" height="72">Denial of Service</td>
      <td width="15%" valign="top" align="center" height="72">Most</td>
      <td valign="top" height="72">Any service made available on a public
        network is likely to be subject to a Denial of Service attack. The
        risk of a Denial of Service attack is generally considered to be
        reduced on closed networks such as internal enterprise networks.</td>
    </tr>
  </tbody>
</table>

<p><a name="__Paragraph_39" id="__Paragraph_39"
class="markParagraph">[39]</a>Where the security requirements of the XKRSS
protocol differ from those of XKISS they are addressed by the XKRSS protocol
directly rather than relying upon the message security binding.</p>

<p><a name="__Paragraph_40" id="__Paragraph_40"
class="markParagraph">[40]</a>For example the XKRSS registration functions
are designed to support use in modes in which a client registration request
is accepted by a Local Registration Authority and then forwarded to a Master
Registration Authority. In this mode it is essential that the proof of
possession of the private key being registered can be verified by both the
Local Registration Authority and the Master Registration Authority, even
though the authentication for the request sent to the Master Registration
Authority is likely to be provided by the Local Registration Authority,
rather than the original requestor. Similar considerations affect the
distribution of private keys..</p>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%">
  <tbody>
    <tr>
      <th width="30%" height="19">Security Issue</th>
      <th width="15%" height="19">Requirement</th>
      <th height="19">Comments</th>
    </tr>
    <tr>
      <td valign="top" width="30%">Confidentiality of Private Key</td>
      <td width="15%" valign="top" align="center">If Server Generated Key
        pairs used</td>
      <td valign="top">If a Register service supports registration of server
        generated key pairs or key recovery strong encryption of the private
        key MUST be supported.</td>
    </tr>
    <tr>
      <td valign="top" width="30%">Registration Request Authentication</td>
      <td width="15%" valign="top" align="center">Some</td>
      <td valign="top">XKMS Registration services SHOULD support the
        authentication of registration requests for initial registration of a
        key binding. Registration requests for secondary registration of
        previously issued credentials (i.e. a signed key binding or a digital
        certificate) MAY be permitted without authentication.</td>
    </tr>
    <tr>
      <td valign="top" width="30%">Registration Proof Of Possession</td>
      <td width="15%" valign="top" align="center">Some</td>
      <td valign="top">XKMS Registration services SHOULD support the
        verification of Proof Of Possession in the initial registration of
        client generated keys.</td>
    </tr>
    <tr>
      <td valign="top" width="30%">Authentication by Revocation Code</td>
      <td width="15%" valign="top" align="center">Some</td>
      <td valign="top">The XKMS Revocation code is self authenticating.</td>
    </tr>
  </tbody>
</table>

<h1><a name="__Section_3" id="__Section_3">3</a> <a name="SOAPBinding"
id="SOAPBinding">SOAP Binding</a></h1>

<p><a name="__Paragraph_41" id="__Paragraph_41"
class="markParagraph">[41]</a>This section describes a mechanism for
communicating the XKMS messages defined in Part 1 of this specification using
the SOAP message protocol. XKMS implementers should support the SOAP message
protocol for interoperability. When doing do, they MUST use the binding
described herein. Bindings for both SOAP 1.2 [SOAP1.2-1][SOAP1.2-2] and SOAP
1.1[SOAP] protocols are specified. Use of SOAP 1.1 is REQUIRED by
implementers in the near term for compatibility with existing tools and
supporting infrastructure. Use of SOAP 1.2 is Recommended.</p>

<h2><a name="__Section_3_1" id="__Section_3_1">3.1</a> <a
name="XKMSSOAPMessageBinding" id="XKMSSOAPMessageBinding">XKMS SOAP Message
Binding</a></h2>

<h3><a name="__Section_3_1_1" id="__Section_3_1_1">3.1.1</a> <a
name="SOAP12Binding" id="SOAP12Binding">SOAP 1.2 Binding</a></h3>

<p><a name="__Paragraph_42" id="__Paragraph_42"
class="markParagraph">[42]</a>XKMS implementers shall use SOAP document style
request-response messaging with the XKMS messages defined in Part 1 carried
as unencoded Body element content. The SOAP 1.2 RPC representation, and
requisite encoding style, are not used. The potential benefits of using the
RPC representation do not justify the additional effort required to define a
mapping from the Part 1 messages to an appropriate encoding style.</p>

<p><a name="__Paragraph_43" id="__Paragraph_43"
class="markParagraph">[43]</a>The XKMS binding shall use the SOAP
Request-Response Message Exchange Pattern defined in [SOAP1.2-2] and message
processing shall conform to that model. SOAP 1.2 messages carrying XKMS
content shall use the UTF-8 character encoding to insure
interoperability..</p>

<p><a name="__Paragraph_44" id="__Paragraph_44"
class="markParagraph">[44]</a>SOAP 1.2 messages carrying XKMS content shall
conform to the following structure:</p>

<p><a name="__Paragraph_45" id="__Paragraph_45"
class="markParagraph">[45]</a>XKMS Request Message</p>
<pre class="Example">&lt;?xml version='1.0' encoding="utf-8"?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
 &lt;env:Header&gt;
  &lt;env:Body&gt;
     XKMS Request Message element
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<p><a name="__Paragraph_46" id="__Paragraph_46"
class="markParagraph">[46]</a>XKMS Response Message</p>
<pre class="Example">&lt;?xml version='1.0' encoding="utf-8"?&gt;&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
 &lt;env:Header&gt;
  &lt;env:Body&gt;
     XKMS Response Message element
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;;</pre>

<p><a name="__Paragraph_47" id="__Paragraph_47"
class="markParagraph">[47]</a>The XKMS SOAP message binding does not require
use of SOAP Headers. Headers may be used with SOAP messages carrying XKMS
content to provide additional services such as communications security or
routing. The use of such Headers is beyond the scope of this specification.
If used however, they must not alter the message encoding style or SOAP
processing model specified herein.</p>

<p><a name="__Paragraph_48" id="__Paragraph_48"
class="markParagraph">[48]</a>Sample XKMS LocateRequest and LocateResponse
message communicated using SOAP 1.2 message transport are shown below:</p>

<p><a name="__Paragraph_49" id="__Paragraph_49"
class="markParagraph">[49]</a>LocateRequest Message</p>
<!-- Include file -->
<pre class="Example">&lt;?xml version="1.0"?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
   &lt;env:Body&gt;
      &lt;LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
            Id="I94d1048aa24259465d7271cb4433dbb4"
            Service="http://test.xmltrustcenter.org/XKMS"
            xmlns="http://www.w3.org/2002/03/xkms#"&gt;
         &lt;RespondWith&gt;KeyName&lt;/RespondWith&gt;
         &lt;RespondWith&gt;KeyValue&lt;/RespondWith&gt;
         &lt;RespondWith&gt;X509Cert&lt;/RespondWith&gt;
         &lt;RespondWith&gt;X509Chain&lt;/RespondWith&gt;
         &lt;RespondWith&gt;PGPWeb&lt;/RespondWith&gt;
         &lt;RespondWith&gt;PGP&lt;/RespondWith&gt;
         &lt;RespondWith&gt;Multiple&lt;/RespondWith&gt;
         &lt;QueryKeyBinding&gt;
            &lt;KeyUsage&gt;Encryption&lt;/KeyUsage&gt;
            &lt;UseKeyWith Application="urn:ietf:rfc:2440"
                  Identifier="bob@bobcorp.test"/&gt;
            &lt;UseKeyWith Application="urn:ietf:rfc:2633"
                  Identifier="bob@bobcorp.test"/&gt;
         &lt;/QueryKeyBinding&gt;
      &lt;/LocateRequest&gt;
   &lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<p><a name="__Paragraph_50" id="__Paragraph_50"
class="markParagraph">[50]</a>LocateResponse Message</p>
<!-- Include file -->
<pre class="Example">&lt;?xml version="1.0"?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
   &lt;env:Body&gt;
      &lt;LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
            Id="I075365c6e4d9feec5abf1d8a4504e4e8"
            Service="http://test.xmltrustcenter.org/XKMS"
            ResultMajor="Success"
            RequestId="#I94d1048aa24259465d7271cb4433dbb4"
            xmlns="http://www.w3.org/2002/03/xkms#"&gt;
         &lt;KeyBinding Id="I9b2502783d8587288b55263b1332c83d"&gt;
            &lt;KeyInfo&gt;
               &lt;ds:KeyValue&gt;
                  &lt;ds:RSAKeyValue&gt;
                     &lt;ds:Modulus&gt;
4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j/
      33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+Mkwm
      opXPVLvhMWRyiUOcO3SEkTE=
&lt;/ds:Modulus&gt;
                     &lt;ds:Exponent&gt;AQAB&lt;/ds:Exponent&gt;
                  &lt;/ds:RSAKeyValue&gt;
               &lt;/ds:KeyValue&gt;
               &lt;ds:X509Data&gt;
                  &lt;ds:X509Certificate&gt;
MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc
      3QgQ0EwHhcNMDIwNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBP
      PUJvYiBDb3JwIENOPUJvYiBCYWtlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2
      qGqYbO0aKeZFb0Z3verx3Cp+KS94LiHG09D1DdgTd48FZaB5eXa4U3mLax2/Fsg/cxGZkXJ
      ur0YylS8QvRuX+9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMUIqO2aN2cbMQJST3
      a2HZuxqPQ1rwXxHrEoAXHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfgY
      CUPpNqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0
      FAAOBgQCieDKjvNCo7MPs
      gUwHydkid4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLD
      FBvH2g7f09xI/vYgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79
      OkYsmwISQlaXejUg==
&lt;/ds:X509Certificate&gt;
                  &lt;ds:X509Certificate&gt;
MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc
      3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0
      IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0
      ee+OYedhMxVh3LXMkMNC++JWDva7H+E9o+uj7dt5cwxHSePsyxPx3Vq+AbEZOsYxGxXgf4O
      uGb8ONBv3B5c8hraOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7dLHsHfKUrVNwIJN
      QIDAQABo1YwVDANBgNVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k2
      oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4G
      BAAynWUPRSbabAEuX0Z8kKN/C2GoEuULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/x
      C9Y+2FMgj68rIas+DId5JMMj+SIZEUV1vPPTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFG
      nki+K9dhv/7trMrfKSSHAPIDQZuz01P
&lt;/ds:X509Certificate&gt;
               &lt;/ds:X509Data&gt;
            &lt;/KeyInfo&gt;
            &lt;KeyUsage&gt;Signature&lt;/KeyUsage&gt;
            &lt;KeyUsage&gt;Encryption&lt;/KeyUsage&gt;
            &lt;KeyUsage&gt;Exchange&lt;/KeyUsage&gt;
            &lt;UseKeyWith Application="urn:ietf:rfc:2633"
                  Identifier="bob@bobcorp.test"/&gt;
            &lt;Status StatusValue="Valid"&gt;
               &lt;Reason&gt;Signature&lt;/Reason&gt;
               &lt;Reason&gt;ValidityInterval&lt;/Reason&gt;
            &lt;/Status&gt;
         &lt;/KeyBinding&gt;
      &lt;/LocateResult&gt;
   &lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<p><a name="__Paragraph_51" id="__Paragraph_51"
class="markParagraph">[51]</a>The structure of conformant SOAP 1.2 messages
carrying other XKMS message types should be evident based on this example.</p>

<h3><a name="__Section_3_1_2" id="__Section_3_1_2">3.1.2</a> <a
name="SOAP11Binding" id="SOAP11Binding">SOAP 1.1 Binding</a></h3>

<p><a name="__Paragraph_52" id="__Paragraph_52"
class="markParagraph">[52]</a>XKMS implementers using SOAP 1.1 messaging
shall use request-response messaging and carry the XKMS messages as unencoded
content within the SOAP Body element. The SOAP 1.1 Section 5 encoding model
shall not be used. SOAP 1.1 messages carrying XKMS content shall use the
UTF-8 character encoding to insure interoperability.</p>

<p><a name="__Paragraph_53" id="__Paragraph_53"
class="markParagraph">[53]</a>The structure of XKMS SOAP 1.1 messages shall
conform to:</p>

<p><a name="__Paragraph_54" id="__Paragraph_54"
class="markParagraph">[54]</a>XKMS Request Message</p>
<pre class="Example">&lt;?xml version='1.0' encoding="utf-8"?&gt;
&lt;env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"&gt;
 &lt;env:Header&gt;
  &lt;env:Body&gt;
     XKMS Request Message element
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<p><a name="__Paragraph_55" id="__Paragraph_55"
class="markParagraph">[55]</a>XKMS Response Message</p>
<pre class="Example">&lt;?xml version='1.0' encoding="utf-8"?&gt;
&lt;env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"&gt;
 &lt;env:Header&gt;
  &lt;env:Body&gt;
     XKMS Response Message element
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<p><a name="__Paragraph_56" id="__Paragraph_56"
class="markParagraph">[56]</a>As with the SOAP 1.2 binding, the SOAP 1.1
binding does not require use of SOAP Headers. Headers may be used with SOAP
messages carrying XKMS content to provide additional services such as
communications security or routing providing they don't impact the encoding
style or SOAP processing model specified herein.</p>

<p><a name="__Paragraph_57" id="__Paragraph_57"
class="markParagraph">[57]</a>SOAP 1.1 messages carrying XKMS content will
are identical to those using SOAP 1.2 except for the namespace of the
Envelope and Body elements. Hence, the examples shown in Section 3.1.1 are
conformant once the SOAP 1.2 namespace is replaced by the SOAP 1.1 namespace
(<a
href="http://schemas.xmlsoap.org/soap/envelope">http://schemas.xmlsoap.org/soap/envelope</a>).</p>

<h2><a name="__Section_3_2" id="__Section_3_2">3.2</a> <a
name="Namespaceinclusions" id="Namespaceinclusions">Namespace
inclusions</a></h2>

<p><a name="__Paragraph_58" id="__Paragraph_58"
class="markParagraph">[58]</a>In using the XKMS SOAP binding, XKMS messages
are constructed as defined in Part 1 of this specification including all
required namespace declarations. The top-level message element is then
inserted as a child of the SOAP Body element. Promotion of XKMS namespace
declarations to the parent SOAP Body (or grandparent Envelope) element is not
required, but may be done at the discretion of the implementer. Such
namespace promotion is generally undesirable if the XKMS message contains a
digital signature as it may impact subsequent verification.</p>

<p><a name="__Paragraph_59" id="__Paragraph_59"
class="markParagraph">[59]</a>Insertion of an XKMS message into the SOAP
message structure must not alter namespace prefixes, or use of default
namespaces, within the XKMS message. Any change in these encodings will
likely break an XML Signature internal to the XKMS messages due to the use of
QNames and namespace prefixes. The implementer must insure that prefix values
used with the SOAP namespaces <a
href="http://www.w3.org/2002/06/soap-envelope/">http://www.w3.org/2002/06/soap-envelope/</a>
(SOAP 1.2) and <a
href="http://schemas.xmlsoap.org/soap/envelope/">http://schemas.xmlsoap.org/soap/envelope/</a>
(SOAP 1.1) do not conflict with prefixes used in the XKMS message.</p>

<h2><a name="__Section_3_3" id="__Section_3_3">3.3</a> <a
name="ComputationofXMLSignatureElements"
id="ComputationofXMLSignatureElements">Computation of XML Signature
Elements</a> in XKMS Messages</h2>

<p><a name="__Paragraph_60" id="__Paragraph_60"
class="markParagraph">[60]</a>Use of the XKMS SOAP binding does not affect
processing of the XML Signature-based elements <span
class="ID">&lt;KeyBindingAuthentication&gt;</span> and <span
class="ID">&lt;ProofOfPossession&gt;</span>. These are computed as described
in XKMS, sections <a
href="http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html#XKMS_2_0_LC2_Section_7_1_4">7.1.4</a>
and <a
href="http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html#XKMS_2_0_LC2_Section_7_1_4">7.1.6</a>
respectively, and the signature validation processing described in XKMS,
section <a
href="http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html#XKMS_2_0_LC2_Section_3_1_2">3.1.2</a>
Element <span class="ID">&lt;ds:Signature&gt;</span>." That is, the SOAP
defined nodes and namespaces do not contribute to the Signature
computation.</p>

<h2><a name="__Section_3_4" id="__Section_3_4">3.4</a> <a
name="UseofSOAPFaults" id="UseofSOAPFaults">Use of SOAP Faults</a></h2>

<p><a name="__Paragraph_61" id="__Paragraph_61"
class="markParagraph">[61]</a>SOAP Faults shall be used by an XKMS service to
communicate errors that prevent the processing of a received XKMS request
message. XKMS clients should never send a SOAP Fault message to an XKMS
service.</p>

<h3><a name="__Section_3_4_1" id="__Section_3_4_1">3.4.1</a> <a
name="SOAP12Faults" id="SOAP12Faults">SOAP 1.2 Faults</a></h3>

<p><a name="__Paragraph_62" id="__Paragraph_62"
class="markParagraph">[62]</a>The following SOAP Fault messages are defined
for use with the XKMS SOAP 1.2 binding. Consistent with the SOAP 1.2
specification, these Fault messages shall contain the mandatory Code and
Reason element information items. Inclusion of other elements is at the
discretion of the implementer.</p>

<p><a name="__Paragraph_63" id="__Paragraph_63"
class="markParagraph">[63]</a>In response to an XKMS request message, the
receiver shall respond with one of the following SOAP Faults if it is unable
to process the message. If it is able to process the message, then the
response should conform to a valid XKMS response message as described in Part
1.</p>
<ol>
  <li>A fault with a Value of "env:VersionMismatch" for Code shall be
    returned when the XKMS service finds an invalid element information item
    instead of the expected Envelope element information item, or the
    namespace, local name or both did not match the required Envelope element
    information item. The Reason element shall be "Unsupported SOAP
  version".</li>
  <li>A fault with a Value of "env:MustUnderstand" for Code shall be returned
    if there is an immediate child element information item of the SOAP
    Header element information item that was either not understood or not
    obeyed by the faulting node when the Header contained a SOAP
    mustUnderstand attribute information item with a value of "true". The
    value for Reason shall be "Unable to process [header element name]" where
    the expression in brackets is replaced by the header element information
    item which caused the initial fault.</li>
  <li>A fault with a Value of "env:Receiver" for Code shall be generated when
    the receiver cannot handle the message because of some temporary
    condition, e.g. when it is out of memory. The Reason shall be "Service
    temporarily unable".</li>
  <li>A fault with a Value of "env:Sender" for Code and a Value of
    "xkms:MessageNotSupported" for Subcode shall be generated when the
    receiver does not support the type of request message. The Reason shall
    be "[XKMS message type] not supported" where the expression in brackets
    is replace by the element information item name corresponding to the
    received XKMS request message.</li>
  <li>A fault with a Value of "env:Sender" for Code and a Value of
    "xkms:BadMessage" for Subcode shall be generated when the receiver cannot
    parse the received XKMS message. The Reason shall be "[XKMS message type]
    invalid" where the expression in brackets is replaced by the element
    information item name corresponding to the received XKMS request
  message.</li>
</ol>

<p><a name="__Paragraph_64" id="__Paragraph_64"
class="markParagraph">[64]</a>A sample SOAP 1.2 fault message that would be
returned when the received XKMS request message isn't supported by the
service is shown below:</p>
<!-- Include file -->
<pre class="Example">&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
 &lt;env:Body&gt;
  &lt;env:Fault&gt;
    &lt;env:Code&gt;
      &lt;env:Value&gt;env:Sender&lt;/env:Value&gt;
      &lt;env:Subcode&gt;
        &lt;env:Value&gt;xkms:MessageNotSupported&lt;/env:Value&gt;
      &lt;/env:Subcode&gt;
    &lt;/env:Code&gt;
    &lt;env:Reason&gt;LocateRequest message not supported&lt;/env:Reason&gt;
   &lt;/env:Fault&gt;
 &lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<h3><a name="__Section_3_4_2" id="__Section_3_4_2">3.4.2</a> <a
name="SOAP11Faults" id="SOAP11Faults">SOAP 1.1 Faults</a></h3>

<p><a name="__Paragraph_65" id="__Paragraph_65"
class="markParagraph">[65]</a>The following SOAP Fault messages are defined
for use with the XKMS SOAP 1.1 binding. Consistent with the SOAP 1.1
specification, these Fault messages shall contain the faultcode and
faultstring elements. Inclusion of other elements is at the discretion of the
implementer.</p>

<p><a name="__Paragraph_66" id="__Paragraph_66"
class="markParagraph">[66]</a>In response to an XKMS request message, the
receiver shall respond with one of the following SOAP Faults if it is unable
to process the message. If it is able to process the message, then the
response should conform to a valid XKMS response message as described in
[XKMS1].</p>
<ol>
  <li>A fault with a faultcode of "env:VersionMismatch" shall be returned
    when the XKMS service doesn't find the expected Envelope element or the
    namespace, local name or both did not match the required Envelope
    element. The faultstring element shall contain "Unsupported SOAP
  version".</li>
  <li>A fault with a faultcode of "env:MustUnderstand" shall be returned if
    there is an immediate child element of the SOAP Header element that was
    either not understood or not obeyed by the faulting node when the header
    contained a SOAP mustUnderstand attribute item with a value of "true".
    The faultstring shall be "Unable to process [header element name]" where
    the expression in brackets is replaced by the first header element
    information item which caused the fault.</li>
  <li>A fault with a faultcode of "env:Server" shall be returned when the
    service cannot handle the message because of some temporary condition,
    e.g. when it is out of memory. The faultstring shall be "Service
    temporarily unable".</li>
  <li>A fault with a faultcode of "env:Client" shall be returned when the
    receiver does not support the type of request message. The value for
    faultstring shall be "[XKMS message type] not supported" where the
    expression in brackets is replace by the element information item name
    corresponding to the received XKMS request message.</li>
  <li>A fault with a faultcode of "env:Client" shall be returned when the
    receiver cannot parse the received XKMS message. The faultstring shall be
    "[XKMS message type] invalid" where the expression in brackets is replace
    by the element information item name corresponding to the received XKMS
    request message.</li>
</ol>

<p><a name="__Paragraph_67" id="__Paragraph_67"
class="markParagraph">[67]</a>A sample SOAP 1.1 fault message that would be
returned when the received XKMS request message isn't supported by the
service is shown below:</p>
<!-- Include file -->
<pre class="Example">&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
 &lt;env:Body&gt;
  &lt;env:Fault&gt;
    &lt;env:faultcode&gt;env:Client&lt;/env:faultcode&gt;
    &lt;env:faultstring&gt;LocateRequest message not supported&lt;/env:faultstring&gt;
   &lt;/env:Fault&gt;
 &lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre>

<h2><a name="__Section_3_5" id="__Section_3_5">3.5</a> <a
name="SOAPoverHTTPbinding" id="SOAPoverHTTPbinding">SOAP over HTTP
binding</a></h2>

<p><a name="__Paragraph_68" id="__Paragraph_68"
class="markParagraph">[68]</a>When the XKMS binding to SOAP 1.2 is
implemented, the SOAP messages should be sent using HTTP POST consistent with
the recommendations of Section 6.4.2 in [SOAP1.2-2]. Processing shall be
consistent with Section 7, SOAP HTTP Binding in that specification.</p>

<p><a name="__Paragraph_69" id="__Paragraph_69"
class="markParagraph">[69]</a>When the XKMS binding to SOAP 1.1 is
implemented, the SOAP messages should be sent using HTTP POST consistent with
the of Section 6.1 in [SOAP].</p>

<h1><a name="__Section_4" id="__Section_4">4</a> <a name="SecurityBindings"
id="SecurityBindings">Security Bindings</a></h1>

<p><a name="__Paragraph_70" id="__Paragraph_70"
class="markParagraph">[70]</a>This specification describes three principal
security bindings each of which specifies two or more specific implementation
profiles. Each implementation profile is assigned a unique URI to facilitate
negotiation of a specific security profile using some mechanism to be
described as a part of the wider Web Services framework.</p>

<table border="1" style="border-collapse: collapse" width="100%"
id="AutoNumber1" cellspacing="0" cellpadding="4">
  <tbody>
    <tr>
      <th align="center">&nbsp;</th>
      <th width="30%">Payload Security</th>
      <th width="30%">Transaction Layer Security</th>
    </tr>
    <tr>
      <td valign="top">Dependencies</td>
      <td width="30%" valign="top">Authentication defined by XKMS
        specification, client does not need to implement a comprehensive
        framework.</td>
      <td width="30%" valign="top">Authentication mechanism defined by TLS
        which clients must implement</td>
    </tr>
    <tr>
      <td valign="top">Use of XML Signature</td>
      <td valign="top" width="30%">Uses XML Signature in Enveloped Mode
        requiring slightly more complex processing.</td>
      <td valign="top" width="30%">Not required</td>
    </tr>
    <tr>
      <td valign="top">Support for Routing</td>
      <td valign="top" width="30%">Specification describes bi-lateral
        authentication only, multi-hop message routing and multi-party
        transactions are not supported.</td>
      <td valign="top" width="30%">None</td>
    </tr>
    <tr>
      <td valign="top">Support for Confidentiality</td>
      <td valign="top" width="30%">None, although applications may employ TLS
        to establish a secure channel</td>
      <td valign="top" width="30%">Supported</td>
    </tr>
    <tr>
      <td valign="top">Non-Repudiation</td>
      <td valign="top" width="30%">Supported</td>
      <td valign="top" width="30%">Requires additional payload security</td>
    </tr>
    <tr>
      <td valign="top">Unspecified Party Authentication</td>
      <td valign="top" width="30%">Supported</td>
      <td valign="top" width="30%">Requires additional payload security</td>
    </tr>
    <tr>
      <td valign="top">Client Authentication</td>
      <td valign="top" width="30%">Supported</td>
      <td valign="top" width="30%">Supported through certificate client
        authentication or through use of payload security.</td>
    </tr>
  </tbody>
</table>

<h2><a name="__Section_4_1" id="__Section_4_1">4.1</a> <a
name="PayloadAuthenticationBinding" id="PayloadAuthenticationBinding">Payload
Authentication Binding</a></h2>
<dl>
  <dt>Identifier: http://www.w3.org/2002/03/xkms#payload-I</dt>
    <dd>No mechanism is used to authenticate the client</dd>
  <dt>Identifier: http://www.w3.org/2002/03/xkms#payload-II</dt>
    <dd>The client is authenticated using payload security</dd>
</dl>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%" id="AutoNumber8">
  <tbody>
    <tr>
      <th width="45%">Security Consideration</th>
      <th width="5%" align="center">Variant</th>
      <th width="15%">Support</th>
      <th>XKMS element</th>
    </tr>
    <tr>
      <td width="45%" align="left"><span style="font-weight: 400">Client
        Authentication Mechanism</span></td>
      <th width="5%" align="center" valign="top">I</th>
      <td width="15%" align="center">None</td>
      <td>&nbsp;</td>
    </tr>
    <tr>
      <th width="45%" align="left">&nbsp;</th>
      <th width="5%" align="center" valign="top">II</th>
      <td width="15%" align="center">Payload</td>
      <td>Request/Signature</td>
    </tr>
    <tr>
      <th width="45%" align="left"><span style="font-weight: 400">Service
        Authentication Mechanism</span></th>
      <th width="5%" align="center" valign="top">&nbsp;</th>
      <td width="15%" align="center">Payload</td>
      <td>Response/Signature</td>
    </tr>
    <tr>
      <th width="45%" align="left"><span
        style="font-weight: 400">Request/Response Correspondence</span></th>
      <th width="5%" align="center" valign="top">I</th>
      <td width="15%" align="center">Payload</td>
      <td>Request/MessageDigest</td>
    </tr>
    <tr>
      <th width="45%" align="left">&nbsp;</th>
      <th width="5%" align="center" valign="top">II</th>
      <td width="15%" align="center">Payload</td>
      <td>Message/RequestID</td>
    </tr>
    <tr>
      <th width="45%" align="left"><span style="font-weight: 400">Replay
        Attack Protection</span></th>
      <th width="5%" align="center" valign="top">&nbsp;</th>
      <td width="15%" align="center">Payload</td>
      <td>Message/Nonce</td>
    </tr>
    <tr>
      <th width="45%" align="left"><span style="font-weight: 400">Denial Of
        Service Protection</span></th>
      <th width="5%" align="center" valign="top">&nbsp;</th>
      <td width="15%" align="center">Payload</td>
      <td><span class="c11">Request/RespondWith=Represent</span></td>
    </tr>
    <tr>
      <th width="45%" align="left"><span style="font-weight: 400">Non
        Repudiation</span></th>
      <th width="5%" align="center" valign="top">&nbsp;</th>
      <td width="15%" align="center">Payload</td>
      <td>Message/Signature with digital signature</td>
    </tr>
  </tbody>
</table>

<p><a name="__Paragraph_71" id="__Paragraph_71"
class="markParagraph">[71]</a>The following payload security features are
employed.</p>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%" id="AutoNumber9">
  <tbody>
    <tr>
      <th width="50%" align="left">XKMS element</th>
      <th width="50%">Required</th>
    </tr>
    <tr>
      <td width="50%" align="left">Message/Service</td>
      <td width="50%">Required</td>
    </tr>
    <tr>
      <td width="50%" align="left">Request/Signature</td>
      <td width="50%">Required in profile II</td>
    </tr>
    <tr>
      <td width="50%" align="left">Response/Signature</td>
      <td width="50%">Required</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/RequestID</td>
      <td width="50%">Required</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/ResponseID</td>
      <td width="50%">Required</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/Nonce</td>
      <td width="50%">Optional, may be used to protect against Denial of
        Service</td>
    </tr>
    <tr>
      <td width="50%" align="left"><span
        class="c11">Request/RespondWith=Represent</span></td>
      <td width="50%">Optional, may be used to protect against Denial of
        Service</td>
    </tr>
    <tr>
      <td width="50%" align="left">Request/MessageDigest</td>
      <td width="50%">Required in profile I, Optional in profile II</td>
    </tr>
  </tbody>
</table>

<h2><a name="__Section_4_2" id="__Section_4_2">4.2</a> <a
name="SecureSocketLayerandTransactionLayer"
id="SecureSocketLayerandTransactionLayer">Secure Socket Layer and Transaction
Layer</a> (SSL/TLS)Security Binding</h2>

<p><a name="__Paragraph_72" id="__Paragraph_72"
class="markParagraph">[72]</a>When TLS is to be used in XKMS, XKMS responders
MUST support server authenticated TLS. Note that this means that an XKMS<br />
client need only support anonymous TLS, since to require otherwise would mean
that all XKMS clients would have to be able to store root certificates for
TLS usage.<br />
<br />
All XKMS clients and responders which support TLS MUST support the
TLS_RSA_WITH_3DES-EDE_CBC_SHA ciphersuite.<br />
Other ciphersuites MAY be supported, but weak ciphersuites intended to meet
export restrictions ("export grade") are NOT RECOMMENDED to be supported."</p>

<p><a name="__Paragraph_73" id="__Paragraph_73"
class="markParagraph">[73]</a>The SSL/TLS binding has three variants
specified by the following identifiers:</p>
<dl>
  <dt>Identifier: http://www.w3.org/2002/03/xkms#tls-I</dt>
    <dd>No mechanism is used to authenticate the client</dd>
  <dt>Identifier: http://www.w3.org/2002/03/xkms#tls-II</dt>
    <dd>TLS certificate based client authentication is used to authenticate
      the client</dd>
  <dt>Identifier: http://www.w3.org/2002/03/xkms#tls-III</dt>
    <dd>Payload security is used for client authentication</dd>
</dl>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%" id="AutoNumber6">
  <tbody>
    <tr>
      <th width="45%">Security Consideration</th>
      <th width="5%" align="center">Variant</th>
      <th width="15%">Support</th>
      <th>XKMS element</th>
    </tr>
    <tr>
      <td width="45%" align="left">Client Authentication Mechanism</td>
      <td width="5%">I</td>
      <td width="15%" align="center">None</td>
      <td width="61%">&nbsp;</td>
    </tr>
    <tr>
      <td width="45%" align="left">&nbsp;</td>
      <td width="5%">II</td>
      <td width="15%" align="center">TLS</td>
      <td width="61%">Certificate based client authentication</td>
    </tr>
    <tr>
      <td width="45%" align="left">&nbsp;</td>
      <td width="5%">II</td>
      <td width="15%" align="center">Payload</td>
      <td width="61%">Request/Signature</td>
    </tr>
    <tr>
      <td width="45%" align="left">Service Authentication Mechanism</td>
      <td width="5%">&nbsp;</td>
      <td width="15%" align="center">TLS</td>
      <td width="61%">&nbsp;</td>
    </tr>
    <tr>
      <td width="45%" align="left">Request/Response Correspondence</td>
      <td width="5%">&nbsp;</td>
      <td width="15%" align="center">TLS</td>
      <td width="61%">&nbsp;</td>
    </tr>
    <tr>
      <td width="45%" align="left">Replay Attack Protection</td>
      <td width="5%">&nbsp;</td>
      <td width="15%" align="center">TLS</td>
      <td width="61%">&nbsp;</td>
    </tr>
    <tr>
      <td width="45%" align="left">Denial Of Service Protection</td>
      <td width="5%">&nbsp;</td>
      <td width="15%" align="center">None</td>
      <td width="61%">The TLS service is subject to a denial of service
        attack [Check this]</td>
    </tr>
    <tr>
      <td width="45%" align="left">Non Repudiation</td>
      <td width="5%">&nbsp;</td>
      <td width="15%" align="center">Payload</td>
      <td width="61%">Message/Signature with digital signature [if
      required]</td>
    </tr>
  </tbody>
</table>

<p><a name="__Paragraph_74" id="__Paragraph_74"
class="markParagraph">[74]</a>The following payload security features are
employed.</p>

<table border="1" cellpadding="4" cellspacing="0"
style="border-collapse: collapse" width="100%" id="AutoNumber7">
  <tbody>
    <tr>
      <th width="50%" align="left">XKMS element</th>
      <th width="50%">Required</th>
    </tr>
    <tr>
      <td width="50%" align="left">Message/Service</td>
      <td width="50%">Required but not dependent</td>
    </tr>
    <tr>
      <td width="50%" align="left">Request/Signature</td>
      <td width="50%">Optional, may be used to support non-repudiation</td>
    </tr>
    <tr>
      <td width="50%" align="left">Response/Signature</td>
      <td width="50%">Optional, may be used to support non-repudiation</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/RequestID</td>
      <td width="50%">Required but not dependent</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/ResponseID</td>
      <td width="50%">Required but not dependent</td>
    </tr>
    <tr>
      <td width="50%" align="left">Message/Nonce</td>
      <td width="50%">Unnecessary</td>
    </tr>
    <tr>
      <td width="50%" align="left"><span
        class="c11">Request/RespondWith=Represent</span></td>
      <td width="50%">Unnecessary</td>
    </tr>
    <tr>
      <td width="50%" align="left">Request/MessageHash</td>
      <td width="50%">Unnecessary</td>
    </tr>
  </tbody>
</table>

<h1 class="appendix"><a name="__Section_Appendix_A"
id="__Section_Appendix_A">Appendix A</a> <a name="References"
id="References">References</a></h1>

<p><a id="ref-KEYWORDS" name="ref-KEYWORDS">[KEYWORDS] </a><a
href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119: Key words for use in
RFCs to Indicate Requirement Levels.</a> S. Bradner. Best Current Practice,
March 1997. <a
href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></p>

<p><a id="PKIX" name="PKIX">[PKIX] </a> TDB</p>

<p><a id="SPKI" name="SPKI">[SPKI] </a> TDB</p>

<p class="Ref"><a name="__Paragraph_75" id="__Paragraph_75"
class="markParagraph">[75]</a> <b>[<a id="SOAP" name="SOAP">SOAP</a>]</b> D.
Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen,
S Thatte, D. Winer. <i>Simple Object Access Protocol (SOAP) 1.1</i>, W3C Note
08 May 2000, <a
href="http://www.w3.org/TR/SOAP/">http://www.w3.org/TR/SOAP/</a></p>

<p class="Ref"><a name="__Paragraph_76" id="__Paragraph_76"
class="markParagraph">[76]</a> <b><a id="XMLP-1"
name="XMLP-1">[SOAP1.2-1]</a></b> W3C Working Draft "SOAP Version 1.2 Part 1:
Messaging Framework", Marting Gudgin, et al, 26 June 2002 (Last call Working
Draft)</p>

<p class="Ref"><a name="__Paragraph_77" id="__Paragraph_77"
class="markParagraph">[77]</a> <b><a id="XMLP-2"
name="XMLP-2">[SOAP1.2-2]</a></b> W3C Working Draft "SOAP Version 1.2 Part 2:
Adjuncts", Martin Gudgin, et al, 26 June 2002 (Last call Working Draft)</p>

<p class="Ref"><a name="__Paragraph_78" id="__Paragraph_78"
class="markParagraph">[78]</a> <b><a id="TLS" name="TLS">[RFC-2246]</a></b>
T. Dierks, C. Allen., <i>The TLS Protocol Version, 1.0.</i>&nbsp;IETF RFC
2246 January 1999. <a
href="http://www.ietf.org/rfc/rfc2246.txt">http://www.ietf.org/rfc/rfc2246.txt</a></p>

<p class="Ref"><a name="__Paragraph_79" id="__Paragraph_79"
class="markParagraph">[79]</a> <b>[<a id="WSSL" name="WSSL">WSDL</a>]</b> E.
Christensen, F. Curbera, G. Meredith, S. Weerawarana, <i>Web Services
Description Language (WSDL) 1.0</i> September 25, 2000, <a
href="http://msdn.microsoft.com/xml/general/wsdl.asp">http://msdn.microsoft.com/xml/general/wsdl.asp</a></p>

<p class="Ref"><a name="__Paragraph_80" id="__Paragraph_80"
class="markParagraph">[80]</a> <b><a name="WSTrustAxiom"
id="WSTrustAxiom">[WSTrustAxiom]</a></b> P. Hallam-Baker et. al., <i>WS-Trust
Axiom</i>, To be published</p>

<p class="Ref"><a name="__Paragraph_81" id="__Paragraph_81"
class="markParagraph">[81]</a> <b>[<a id="XML-SIG"
name="XML-SIG">XML-SIG</a>]</b>&nbsp; D. Eastlake, J. R., D. Solo, M. Bartel,
J. Boyer , B. Fox , E. Simon. <i>XML-Signature Syntax and Processing</i>,
World Wide Web Consortium. <a
href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a></p>

<p class="Ref"><a name="__Paragraph_82" id="__Paragraph_82"
class="markParagraph">[82]</a> <b>[<a id="XML-SIG-XSD"
name="XML-SIG-XSD">XML-SIG-XSD</a>]</b> XML Signature Schema available from
<span class="731370520-26032003"><font face="Arial"><a
href="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd</a></font></span></p>

<p class="Ref"><a name="__Paragraph_83" id="__Paragraph_83"
class="markParagraph">[83]</a> <b>[<a id="XML-Enc"
name="XML-Enc">XML-Enc</a>]</b>Donald Eastlake, Joseph Reagle, Takeshi
Imamura, Blair Dillaway, Ed Simon, <i>XML Encryption Syntax and
Processing</i>, World Wide Web Consortium, <a
href="http://www.w3.org/TR/xmlenc-core/">http://www.w3.org/TR/xmlenc-core/</a></p>

<p>[<a
id="ref-XML-NS">XML-ns</a>]T. Bray, D. Hollander, A. Layman.
<i>Namespaces in XML. W3C Recommendation.</i> January 1999. <a
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114</a></p>

<p class="Ref"><a name="__Paragraph_84" id="__Paragraph_84"
class="markParagraph">[84]</a> <b>[<a id="XML-Schema1"
name="XML-Schema1">XML-Schema1</a>]</b> H. S. Thompson, D. Beech, M. Maloney,
N. Mendelsohn. <i>XML Schema Part 1: Structures</i>, W3C Working Draft 22
September 2000, <a
href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/">http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/</a>,
latest draft at <a
href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a></p>

<p class="Ref"><a name="__Paragraph_85" id="__Paragraph_85"
class="markParagraph">[85]</a> <b>[<a id="XML-Schema2"
name="XML-Schema2">XML-Schema2</a>]</b> P. V. Biron, A. Malhotra, <i>XML
Schema Part 2: Datatypes</i>; W3C Working Draft 22 September 2000, <a
href="http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/">http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/</a>,
latest draft at <a
href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a></p>
</body>
</html>