You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1502 lines
67 KiB
1502 lines
67 KiB
<?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> </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 (<<a
|
|
href="mailto:pbaker@verisign.com">pbaker@verisign.com</a>>) 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, 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 (Microsoft), Dr Paul Boisen (NSA), 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 <RequestSignatureValue> 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"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Header>
|
|
<env:Body>
|
|
XKMS Request Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="__Paragraph_46" id="__Paragraph_46"
|
|
class="markParagraph">[46]</a>XKMS Response Message</p>
|
|
<pre class="Example"><?xml version='1.0' encoding="utf-8"?><env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Header>
|
|
<env:Body>
|
|
XKMS Response Message element
|
|
</env:Body>
|
|
</env:Envelope>;</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"><?xml version="1.0"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Body>
|
|
<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#">
|
|
<RespondWith>KeyName</RespondWith>
|
|
<RespondWith>KeyValue</RespondWith>
|
|
<RespondWith>X509Cert</RespondWith>
|
|
<RespondWith>X509Chain</RespondWith>
|
|
<RespondWith>PGPWeb</RespondWith>
|
|
<RespondWith>PGP</RespondWith>
|
|
<RespondWith>Multiple</RespondWith>
|
|
<QueryKeyBinding>
|
|
<KeyUsage>Encryption</KeyUsage>
|
|
<UseKeyWith Application="urn:ietf:rfc:2440"
|
|
Identifier="bob@bobcorp.test"/>
|
|
<UseKeyWith Application="urn:ietf:rfc:2633"
|
|
Identifier="bob@bobcorp.test"/>
|
|
</QueryKeyBinding>
|
|
</LocateRequest>
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="__Paragraph_50" id="__Paragraph_50"
|
|
class="markParagraph">[50]</a>LocateResponse Message</p>
|
|
<!-- Include file -->
|
|
<pre class="Example"><?xml version="1.0"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Body>
|
|
<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#">
|
|
<KeyBinding Id="I9b2502783d8587288b55263b1332c83d">
|
|
<KeyInfo>
|
|
<ds:KeyValue>
|
|
<ds:RSAKeyValue>
|
|
<ds:Modulus>
|
|
4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j/
|
|
33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+Mkwm
|
|
opXPVLvhMWRyiUOcO3SEkTE=
|
|
</ds:Modulus>
|
|
<ds:Exponent>AQAB</ds:Exponent>
|
|
</ds:RSAKeyValue>
|
|
</ds:KeyValue>
|
|
<ds:X509Data>
|
|
<ds:X509Certificate>
|
|
MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc
|
|
3QgQ0EwHhcNMDIwNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBP
|
|
PUJvYiBDb3JwIENOPUJvYiBCYWtlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2
|
|
qGqYbO0aKeZFb0Z3verx3Cp+KS94LiHG09D1DdgTd48FZaB5eXa4U3mLax2/Fsg/cxGZkXJ
|
|
ur0YylS8QvRuX+9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMUIqO2aN2cbMQJST3
|
|
a2HZuxqPQ1rwXxHrEoAXHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfgY
|
|
CUPpNqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0
|
|
FAAOBgQCieDKjvNCo7MPs
|
|
gUwHydkid4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLD
|
|
FBvH2g7f09xI/vYgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79
|
|
OkYsmwISQlaXejUg==
|
|
</ds:X509Certificate>
|
|
<ds:X509Certificate>
|
|
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
|
|
</ds:X509Certificate>
|
|
</ds:X509Data>
|
|
</KeyInfo>
|
|
<KeyUsage>Signature</KeyUsage>
|
|
<KeyUsage>Encryption</KeyUsage>
|
|
<KeyUsage>Exchange</KeyUsage>
|
|
<UseKeyWith Application="urn:ietf:rfc:2633"
|
|
Identifier="bob@bobcorp.test"/>
|
|
<Status StatusValue="Valid">
|
|
<Reason>Signature</Reason>
|
|
<Reason>ValidityInterval</Reason>
|
|
</Status>
|
|
</KeyBinding>
|
|
</LocateResult>
|
|
</env:Body>
|
|
</env:Envelope></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"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
|
|
<env:Header>
|
|
<env:Body>
|
|
XKMS Request Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="__Paragraph_55" id="__Paragraph_55"
|
|
class="markParagraph">[55]</a>XKMS Response Message</p>
|
|
<pre class="Example"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope">
|
|
<env:Header>
|
|
<env:Body>
|
|
XKMS Response Message element
|
|
</env:Body>
|
|
</env:Envelope></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"><KeyBindingAuthentication></span> and <span
|
|
class="ID"><ProofOfPossession></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"><ds:Signature></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"><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Body>
|
|
<env:Fault>
|
|
<env:Code>
|
|
<env:Value>env:Sender</env:Value>
|
|
<env:Subcode>
|
|
<env:Value>xkms:MessageNotSupported</env:Value>
|
|
</env:Subcode>
|
|
</env:Code>
|
|
<env:Reason>LocateRequest message not supported</env:Reason>
|
|
</env:Fault>
|
|
</env:Body>
|
|
</env:Envelope></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"><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
|
|
<env:Body>
|
|
<env:Fault>
|
|
<env:faultcode>env:Client</env:faultcode>
|
|
<env:faultstring>LocateRequest message not supported</env:faultstring>
|
|
</env:Fault>
|
|
</env:Body>
|
|
</env:Envelope></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"> </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> </td>
|
|
</tr>
|
|
<tr>
|
|
<th width="45%" align="left"> </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"> </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"> </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"> </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"> </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"> </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%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="45%" align="left"> </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"> </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%"> </td>
|
|
<td width="15%" align="center">TLS</td>
|
|
<td width="61%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="45%" align="left">Request/Response Correspondence</td>
|
|
<td width="5%"> </td>
|
|
<td width="15%" align="center">TLS</td>
|
|
<td width="61%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="45%" align="left">Replay Attack Protection</td>
|
|
<td width="5%"> </td>
|
|
<td width="15%" align="center">TLS</td>
|
|
<td width="61%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="45%" align="left">Denial Of Service Protection</td>
|
|
<td width="5%"> </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%"> </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> 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> 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>
|