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.
1458 lines
77 KiB
1458 lines
77 KiB
<?xml version="1.0"?>
|
|
<!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 profile="http://www.w3.org/2000/08/w3c-synd/#"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|
<title>XML Key Management Specification (XKMS 2.0) Bindings</title>
|
|
<style type="text/css" xml:space="preserve">
|
|
<!-- /*<![CDATA[*/
|
|
p.Code { 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 { }
|
|
p.toc1 { text-align: left; margin-left: 1pt; margin-top: 6pt;
|
|
margin-bottom: 1pt }
|
|
p.toc2 { line-height: 100%; margin-top: 4pt; margin-bottom: 0 }
|
|
p.toc3 { line-height: 100%; margin-top: 2pt; margin-bottom: 10pt }
|
|
span.ID { font-family: Courier }
|
|
pre.Code { 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 { 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 { background-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 }
|
|
|
|
div.contents ul li { font-weight: bold }
|
|
div.contents ul li ul li { font-weight: normal }
|
|
/*]]>*/ -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC" />
|
|
</head>
|
|
|
|
<body xml:lang="EN-US" lang="EN-US">
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/" shape="rect"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a>
|
|
|
|
<h1 class="NoNumber" id="title"><a name="XKMS_2_0_Section_Marker_1" shape="rect" id="XKMS_2_0_Section_Marker_1">XML Key
|
|
Management Specification (XKMS 2.0) Bindings</a></h1>
|
|
|
|
<h2 class="NoNumber" id="version"><a name="XKMS_2_0_Section_Marker_2" shape="rect" id="XKMS_2_0_Section_Marker_2">Version
|
|
2.0</a></h2>
|
|
|
|
<h2 class="NoNumber" id="W3C-doctype"><a name="XKMS_2_0_Section_Marker_3" shape="rect" id="XKMS_2_0_Section_Marker_3"></a><a name="Masthead" id="Masthead" shape="rect">W3C Recommendation 28 June 2005</a></h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2005/REC-xkms2-bindings-20050628/" shape="rect">http://www.w3.org/TR/2005/REC-xkms2-bindings-20050628/</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/xkms2-bindings/" shape="rect">http://www.w3.org/TR/xkms2-bindings/</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2005/PR-xkms2-bindings-20050502/" shape="rect">http://www.w3.org/TR/2005/PR-xkms2-bindings-20050502/</a> </dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Phillip Hallam-Baker, Verisign</dd>
|
|
<dd>Shivaram H. Mysore</dd>
|
|
<dt>Contributors:</dt>
|
|
<dd>See the <a href="#Acknowledgments" shape="rect">Acknowledgments</a>.</dd>
|
|
</dl>
|
|
|
|
<p>Please refer to the <a
|
|
href="http://www.w3.org/2005/06/xkms2-errata.html"><strong>errata</strong></a>
|
|
for this document, which may include some normative corrections.</p>
|
|
|
|
<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xkms2-bindings"><strong>translations</strong></a>.</p>
|
|
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> ©2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></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> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
|
|
</div>
|
|
<hr title="Separator from Header" />
|
|
|
|
<div>
|
|
<h2 class="Abstract"><a name="XKMS_2_0_Section_Marker_4" id="XKMS_2_0_Section_Marker_4" shape="rect"></a><a id="abstract" name="abstract" shape="rect">Abstract</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_2" id="XKMS_2_0_Paragraph_2"
|
|
class="markParagraph" shape="rect">[2]</a>This document specifies
|
|
protocol bindings with security characteristics for the <a
|
|
href="http://www.w3.org/TR/2005/REC-xkms2-20050628/" shape="rect">XML
|
|
Key Management Specification (XKMS</a>).</p>
|
|
|
|
<h2 class="NoNumber"><a name="XKMS_2_0_Section_Marker_5" id="XKMS_2_0_Section_Marker_5" shape="rect"></a><a name="status" id="status" shape="rect">Status of
|
|
this document</a></h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its
|
|
publication. Other documents may supersede this document. A list of current
|
|
W3C publications and the latest revision of this technical report can be
|
|
found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
|
|
at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This document is a <a href="/2003/06/Process-20030618/tr.html#RecsW3C">W3C
|
|
Recommendation</a>. It has been reviewed by W3C Members and other interested
|
|
parties and has been endorsed by the Director. It is a stable document and
|
|
may be used as reference material or cited as a normative reference from
|
|
another document. W3C's role in making the Recommendation is to draw
|
|
attention to the specification and to promote its widespread deployment. This
|
|
enhances the functionality and interoperability of the Web.</p>
|
|
|
|
<p>This document has been produced by the <a
|
|
href="http://www.w3.org/2001/XKMS/" shape="rect">XKMS Working
|
|
Group</a> (WG). The English version of this specification is the only
|
|
normative version. <a
|
|
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xkms2-bindings">
|
|
Translations</a> of this document may be available.</p>
|
|
|
|
<p>If you have any comments on this document, send them to <a
|
|
href="mailto:www-xkms@w3.org" shape="rect">www-xkms@w3.org</a>, a
|
|
mailing list with a <a
|
|
href="http://lists.w3.org/Archives/Public/www-xkms/"
|
|
shape="rect">public archive</a>. An <a
|
|
href="http://www.w3.org/2005/06/xkms2-errata">errata list</a> for this
|
|
edition is available.</p>
|
|
|
|
<p>This is Part 2 of the W3C Recommendation for the XML Key
|
|
Management Specification (XKMS Version 2.0). This document covers
|
|
different protocol bindings with security characteristics for the XML
|
|
Key Management Specification. <a
|
|
href="http://www.w3.org/TR/2005/REC-xkms2-20050628/ ">Part 1</a> of
|
|
this specification covers the XKMS protocols and services. For
|
|
background on this work, please see the <a
|
|
href="http://www.w3.org/2001/XKMS/Activity" shape="rect">XKMS Activity
|
|
Statement</a>.</p>
|
|
|
|
<p>This document is based on the <a
|
|
href="/TR/2005/PR-xkms2-bindings-20050502/">XKMS Version 2.0 Bindings
|
|
Proposed Recommendation</a> of 2 May 2005. <a
|
|
href="/2001/XKMS/Drafts/pr-issues/issues.html">Feedback</a> received during
|
|
that review resulted in minor editorial changes. Evidence of interoperation
|
|
between at least two implementations of this specification are documented in
|
|
the <a
|
|
href="/2001/XKMS/Drafts/test-suite/CR-XKMS-Summary.html">Implementation
|
|
Report</a>. Changes to this document since the Proposed Recommendation
|
|
version are detailed in <a href="#XKMS_2_0_Section_Appendix_C">Appendix
|
|
C</a>.</p>
|
|
|
|
<p>This document was produced under the <a
|
|
href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24
|
|
January 2002 CPP</a> as amended by the <a
|
|
href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy
|
|
Transition Procedure</a>. The Working Group maintains a <a
|
|
rel="disclosure"
|
|
href="http://www.w3.org/2001/XKMS/Disclosures.html">public list of
|
|
patent disclosures</a> relevant to this document; that page also
|
|
includes instructions for disclosing a patent. An individual who has
|
|
actual knowledge of a patent which the individual believes contains
|
|
Essential Claim(s) with respect to this specification should disclose
|
|
the information in accordance with <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
|
|
6 of the W3C Patent Policy</a>.</p>
|
|
|
|
<hr title="Separator from Header" />
|
|
</div>
|
|
|
|
<!-- *************************** -->
|
|
<!-- TABLE OF CONTENTS -->
|
|
<!-- *************************** -->
|
|
|
|
<div class="contents">
|
|
|
|
<h2 class="no-toc" id="toc"><a name="XKMS_2_0_Section_Marker_6" id="XKMS_2_0_Section_Marker_6" shape="rect"></a><a name="TableOfContents" id="TableOfContents" shape="rect">Table of Contents</a></h2>
|
|
|
|
<ul class="toc">
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_1" shape="rect">1 Introduction</a>
|
|
<ul class="toc">
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_1_1" shape="rect">1.1 Editorial and Conformance
|
|
Conventions</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_1_2" shape="rect">1.2 Definition of
|
|
Terms</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_1_3" shape="rect">1.3 Structure of this
|
|
document</a></li>
|
|
</ul></li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2" shape="rect">2 Security Requirements</a>
|
|
<ul class="toc">
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_1" shape="rect">2.1 Confidentiality</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_2" shape="rect">2.2 Request
|
|
Authentication</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_3" shape="rect">2.3 Response
|
|
Authentication</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_4" shape="rect">2.4 Persistent
|
|
Authentication</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_5" shape="rect">2.5 Message Correlation
|
|
(Response Replay and Request Substitution)</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_6" shape="rect">2.6 Request Replay</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_7" shape="rect">2.7 Denial of Service</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_2_8" shape="rect">2.8 Security Requirements
|
|
Summary</a></li>
|
|
</ul></li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3" shape="rect">3 SOAP Binding</a>
|
|
<ul class="toc">
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3_1" shape="rect">3.1 XKMS SOAP Message
|
|
Binding</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3_2" shape="rect">3.2 Namespace
|
|
inclusions</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3_3" shape="rect">3.3 Computation of XML
|
|
Signature Elements in XKMS Messages</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3_4" shape="rect">3.4 Use of SOAP Faults</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_3_5" shape="rect">3.5 SOAP over HTTP
|
|
binding</a></li>
|
|
</ul></li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_4" shape="rect">4 Security Bindings</a>
|
|
<ul class="toc">
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_4_1" shape="rect">4.1 Payload Authentication
|
|
Binding</a></li>
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_4_2" shape="rect">4.2 Secure Socket Layer and
|
|
Transaction Layer (SSL/TLS)Security Binding</a></li>
|
|
</ul></li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_Appendix_A" shape="rect">Appendix A
|
|
References</a> (Non-Normative)</li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_Appendix_B" shape="rect">Appendix B Acknowledgments</a> (Non-Normative)</li>
|
|
|
|
<li class="tocline"><a href="#XKMS_2_0_Section_Appendix_C" shape="rect">Appendix C
|
|
Changes</a> (Non-Normative)</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<h1><a name="XKMS_2_0_Section_1" id="XKMS_2_0_Section_1" shape="rect">1</a> <a name="Introduction" id="Introduction" shape="rect">Introduction</a></h1>
|
|
|
|
<h2><a name="XKMS_2_0_Section_1_1" id="XKMS_2_0_Section_1_1" shape="rect">1.1</a> <a name="sec-Editorial" id="sec-Editorial" shape="rect">Editorial</a> and Conformance
|
|
Conventions</h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_8" id="XKMS_2_0_Paragraph_8" class="markParagraph" shape="rect">[8]</a>This specification uses XML Schemas [<a href="#XML-Schema1" shape="rect">XML-schema</a>] to describe the content model.</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_9" id="XKMS_2_0_Paragraph_9" class="markParagraph" shape="rect">[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="#ref-KEYWORDS" shape="rect">RFC2119</a>]:</p>
|
|
|
|
<blockquote>
|
|
<p><a name="XKMS_2_0_Paragraph_10" id="XKMS_2_0_Paragraph_10" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_11" id="XKMS_2_0_Paragraph_11" class="markParagraph" shape="rect">[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" shape="rect">XML-NS</a>] is described as
|
|
"REQUIRED."</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_1_2" id="XKMS_2_0_Section_1_2" shape="rect">1.2</a> <a name="DefinitionofTerms" id="DefinitionofTerms" shape="rect">Definition of Terms</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_14" id="XKMS_2_0_Paragraph_14" class="markParagraph" shape="rect">[14]</a>This document uses the terms defined in <a href="http://www.w3.org/TR/2005/REC-xkms2-20050628/#DefinitionofTerms" shape="rect">Section 1.2</a> of part
|
|
one of this specification in the manner described therein.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_1_3" id="XKMS_2_0_Section_1_3" shape="rect">1.3</a> <a name="Structureofthisdocument" id="Structureofthisdocument" shape="rect">Structure of this
|
|
document</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_15" id="XKMS_2_0_Paragraph_15" class="markParagraph" shape="rect">[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="XKMS_2_0_Section_2" id="XKMS_2_0_Section_2" shape="rect">2</a> <a name="SecurityRequirements" id="SecurityRequirements" shape="rect">Security
|
|
Requirements</a></h1>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_16" id="XKMS_2_0_Paragraph_16" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_17" id="XKMS_2_0_Paragraph_17" class="markParagraph" shape="rect">[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="XKMS_2_0_Section_2_1" id="XKMS_2_0_Section_2_1" shape="rect">2.1</a> <a name="Confidentiality" id="Confidentiality" shape="rect">Confidentiality</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_18" id="XKMS_2_0_Paragraph_18" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_19" id="XKMS_2_0_Paragraph_19" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_20" id="XKMS_2_0_Paragraph_20" class="markParagraph" shape="rect">[20]</a>An XKMS service SHOULD support Confidentiality
|
|
by means of encryption.</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_21" id="XKMS_2_0_Paragraph_21" class="markParagraph" shape="rect">[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 signing key obtained using some other retrieval mechanism such as
|
|
PKIX [<a href="#RFC3280" shape="rect">RFC3280</a>] or SPKI [<a href="#RFC2693" shape="rect">RFC2693</a>].</li>
|
|
</ul>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_22" id="XKMS_2_0_Paragraph_22" class="markParagraph" shape="rect">[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="XKMS_2_0_Section_2_2" id="XKMS_2_0_Section_2_2" shape="rect">2.2</a> <a name="RequestAuthentication" id="RequestAuthentication" shape="rect">Request
|
|
Authentication</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_23" id="XKMS_2_0_Paragraph_23" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_24" id="XKMS_2_0_Paragraph_24" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_25" id="XKMS_2_0_Paragraph_25" class="markParagraph" shape="rect">[25]</a>An XKMS service SHOULD support Message Request
|
|
Authentication.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_2_3" id="XKMS_2_0_Section_2_3" shape="rect">2.3</a> <a name="ResponseAuthentication" id="ResponseAuthentication" shape="rect">Response
|
|
Authentication</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_26" id="XKMS_2_0_Paragraph_26" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_27" id="XKMS_2_0_Paragraph_27" class="markParagraph" shape="rect">[27]</a>Note that Message Response Authentication is
|
|
considered separately from Response Replay Protection.</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_28" id="XKMS_2_0_Paragraph_28" class="markParagraph" shape="rect">[28]</a>An XKMS service SHOULD support Request
|
|
Authentication.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_2_4" id="XKMS_2_0_Section_2_4" shape="rect">2.4</a> <a name="PersistentAuthentication" id="PersistentAuthentication" shape="rect">Persistent
|
|
Authentication</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_29" id="XKMS_2_0_Paragraph_29" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_30" id="XKMS_2_0_Paragraph_30" class="markParagraph" shape="rect">[30]</a>An XKMS service MAY support Persistent
|
|
Authentication by means of a digital signature on the message.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_2_5" id="XKMS_2_0_Section_2_5" shape="rect">2.5</a> <a name="MessageCorrelation" id="MessageCorrelation" shape="rect">Message Correlation</a>
|
|
(Response Replay and Request Substitution)</h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_31" id="XKMS_2_0_Paragraph_31" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_32" id="XKMS_2_0_Paragraph_32" class="markParagraph" shape="rect">[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="XKMS_2_0_Section_2_6" id="XKMS_2_0_Section_2_6" shape="rect">2.6</a> <a name="RequestReplay" id="RequestReplay" shape="rect">Request Replay</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_33" id="XKMS_2_0_Paragraph_33" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_34" id="XKMS_2_0_Paragraph_34" class="markParagraph" shape="rect">[34]</a>An XKMS service MAY provide protection against
|
|
a Request Replay.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_2_7" id="XKMS_2_0_Section_2_7" shape="rect">2.7</a> <a name="DenialofService" id="DenialofService" shape="rect">Denial of Service</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_35" id="XKMS_2_0_Paragraph_35" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_36" id="XKMS_2_0_Paragraph_36" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_37" id="XKMS_2_0_Paragraph_37" class="markParagraph" shape="rect">[37]</a>An XKMS service SHOULD support protection
|
|
against a Denial of Service attack.</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_2_8" id="XKMS_2_0_Section_2_8" shape="rect">2.8</a> <a name="SecurityRequirementsSummary" id="SecurityRequirementsSummary" shape="rect">Security
|
|
Requirements Summary</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_38" id="XKMS_2_0_Paragraph_38" class="markParagraph" shape="rect">[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" width="100%">
|
|
<thead>
|
|
<tr>
|
|
<th width="30%" height="19" >Security Issue</th>
|
|
<th width="15%" >Requirement</th>
|
|
<th height="19" >Comments</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<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 Replay</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="XKMS_2_0_Paragraph_39" id="XKMS_2_0_Paragraph_39" class="markParagraph" shape="rect">[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="XKMS_2_0_Paragraph_40" id="XKMS_2_0_Paragraph_40" class="markParagraph" shape="rect">[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" width="100%">
|
|
<thead>
|
|
<tr>
|
|
<th width="30%" height="19" >Security Issue</th>
|
|
<th width="15%" height="19" >Requirement</th>
|
|
<th height="19" >Comments</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<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="XKMS_2_0_Section_3" id="XKMS_2_0_Section_3" shape="rect">3</a> <a name="SOAPBinding" id="SOAPBinding" shape="rect">SOAP Binding</a></h1>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_41" id="XKMS_2_0_Paragraph_41" class="markParagraph" shape="rect">[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.</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_42" id="XKMS_2_0_Paragraph_42" class="markParagraph" shape="rect">[42]</a>XKMS 2.0 implementations MUST support the use
|
|
of SOAP 1.2. For near term compatibility with existing tools and
|
|
infrastructure, SOAP 1.1 MAY be used</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_3_1" id="XKMS_2_0_Section_3_1" shape="rect">3.1</a> <a name="XKMSSOAPMessageBinding" id="XKMSSOAPMessageBinding" shape="rect">XKMS SOAP Message
|
|
Binding</a></h2>
|
|
|
|
<h3><a name="XKMS_2_0_Section_3_1_1" id="XKMS_2_0_Section_3_1_1" shape="rect">3.1.1</a> <a name="SOAP12Binding" id="SOAP12Binding" shape="rect">SOAP 1.2 Binding</a></h3>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_43" id="XKMS_2_0_Paragraph_43"
|
|
class="markParagraph" shape="rect">[43]</a>XKMS implementers shall use
|
|
SOAP document style request-response messaging with the XKMS messages
|
|
defined in Part 1 carried as literal Body element content. This is
|
|
equivalent to associating the Body content with a SOAP 1.2 <span
|
|
class="ID"><a
|
|
href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapencattr">
|
|
env:encodingStyle</a></span> attribute that has the value <span
|
|
class="ID">http://www.w3.org/2003/05/soap-envelope/encoding/none</span>.</p>
|
|
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_44" id="XKMS_2_0_Paragraph_44" class="markParagraph" shape="rect">[44]</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="XKMS_2_0_Paragraph_45" id="XKMS_2_0_Paragraph_45" class="markParagraph" shape="rect">[45]</a>SOAP 1.2 messages carrying XKMS content shall
|
|
conform to the following structure:</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_46" id="XKMS_2_0_Paragraph_46" class="markParagraph" shape="rect">[46]</a>XKMS Request Message</p>
|
|
<pre class="Example" xml:space="preserve"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
|
|
<env:Body>
|
|
XKMS Request Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_47" id="XKMS_2_0_Paragraph_47" class="markParagraph" shape="rect">[47]</a>XKMS Response Message</p>
|
|
<pre class="Example" xml:space="preserve"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
|
|
<env:Body>
|
|
XKMS Response Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_48" id="XKMS_2_0_Paragraph_48" class="markParagraph" shape="rect">[48]</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="XKMS_2_0_Paragraph_49" id="XKMS_2_0_Paragraph_49" class="markParagraph" shape="rect">[49]</a>Sample XKMS LocateRequest and LocateResponse
|
|
message communicated using SOAP 1.2 message transport are shown below:</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_50" id="XKMS_2_0_Paragraph_50" class="markParagraph" shape="rect">[50]</a>LocateRequest Message</p>
|
|
<!-- Include file -->
|
|
<pre class="Example" xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
|
|
<env:Body>
|
|
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
|
|
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
|
|
Id="I8fc9f97052a34073312b22a69b3843b6"
|
|
Service="http://www.example.org/XKMS"
|
|
xmlns="http://www.w3.org/2002/03/xkms#">
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
|
|
<RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
|
|
<QueryKeyBinding>
|
|
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
|
|
<UseKeyWith Application="urn:ietf:rfc:2440"
|
|
Identifier="bob@example.com" />
|
|
<UseKeyWith Application="urn:ietf:rfc:2633"
|
|
Identifier="bob@example.com" />
|
|
</QueryKeyBinding>
|
|
</LocateRequest>
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_51" id="XKMS_2_0_Paragraph_51" class="markParagraph" shape="rect">[51]</a>LocateResponse Message</p>
|
|
<!-- Include file -->
|
|
<pre class="Example" xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
|
|
<env:Body>
|
|
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
|
|
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
|
|
Id="I8ce3809ab23500015cc27704b7eb0912"
|
|
Service="http://www.example.org/XKMS"
|
|
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
|
|
RequestId="I8fc9f97052a34073312b22a69b3843b6"
|
|
xmlns="http://www.w3.org/2002/03/xkms#">
|
|
<UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d">
|
|
<ds:KeyInfo>
|
|
<ds:KeyValue>
|
|
<ds:RSAKeyValue>
|
|
<ds:Modulus>
|
|
3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
|
|
UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
|
|
WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
|
|
</ds:Modulus>
|
|
<ds:Exponent>AQAB</ds:Exponent>
|
|
</ds:RSAKeyValue>
|
|
</ds:KeyValue>
|
|
<ds:X509Data>
|
|
<ds:X509Certificate>
|
|
MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
|
|
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
|
|
AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
|
|
Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
|
|
O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
|
|
MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
|
|
wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
|
|
UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
|
|
D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
|
|
B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
|
|
q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
|
|
hb+XNyn
|
|
</ds:X509Certificate>
|
|
<ds:X509Certificate>
|
|
MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
|
|
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
|
|
ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
|
|
QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
|
|
fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
|
|
C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
|
|
NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
|
|
A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
|
|
ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
|
|
QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
|
|
tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
|
|
</ds:X509Certificate>
|
|
</ds:X509Data>
|
|
</ds:KeyInfo>
|
|
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
|
|
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
|
|
<KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
|
|
<UseKeyWith Application="urn:ietf:rfc:2633"
|
|
Identifier="bob@example.com"/>
|
|
</UnverifiedKeyBinding>
|
|
</LocateResult>
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_52" id="XKMS_2_0_Paragraph_52" class="markParagraph" shape="rect">[52]</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="XKMS_2_0_Section_3_1_2" id="XKMS_2_0_Section_3_1_2" shape="rect">3.1.2</a> <a name="SOAP11Binding" id="SOAP11Binding" shape="rect">SOAP 1.1 Binding</a></h3>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_53" id="XKMS_2_0_Paragraph_53" class="markParagraph" shape="rect">[53]</a>XKMS implementers using SOAP 1.1 messaging
|
|
shall use request-response messaging and carry the XKMS messages as literal
|
|
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="XKMS_2_0_Paragraph_54" id="XKMS_2_0_Paragraph_54" class="markParagraph" shape="rect">[54]</a>The structure of XKMS SOAP 1.1 messages shall
|
|
conform to:</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_55" id="XKMS_2_0_Paragraph_55" class="markParagraph" shape="rect">[55]</a>XKMS Request Message</p>
|
|
<pre class="Example" xml:space="preserve"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
|
|
<env:Body>
|
|
XKMS Request Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_56" id="XKMS_2_0_Paragraph_56" class="markParagraph" shape="rect">[56]</a>XKMS Response Message</p>
|
|
<pre class="Example" xml:space="preserve"><?xml version='1.0' encoding="utf-8"?>
|
|
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
|
|
<env:Body>
|
|
XKMS Response Message element
|
|
</env:Body>
|
|
</env:Envelope></pre>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_57" id="XKMS_2_0_Paragraph_57" class="markParagraph" shape="rect">[57]</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="XKMS_2_0_Paragraph_58" id="XKMS_2_0_Paragraph_58" class="markParagraph" shape="rect">[58]</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/" shape="rect">http://schemas.xmlsoap.org/soap/envelope/</a>).</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_3_2" id="XKMS_2_0_Section_3_2" shape="rect">3.2</a> <a name="Namespaceinclusions" id="Namespaceinclusions" shape="rect">Namespace
|
|
inclusions</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_59" id="XKMS_2_0_Paragraph_59" class="markParagraph" shape="rect">[59]</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="XKMS_2_0_Paragraph_60" id="XKMS_2_0_Paragraph_60" class="markParagraph" shape="rect">[60]</a>XKMS messages that will be embedded in SOAP documents SHOULD be
|
|
signed using the Exclusive XML Canonicalization algorithm [<a href="#XML-EXC-C14N" shape="rect">XML-EXC-C14N</a>].</p>
|
|
|
|
<h2><a name="XKMS_2_0_Section_3_3" id="XKMS_2_0_Section_3_3" shape="rect">3.3</a> <a name="ComputationofXMLSignatureElements" id="ComputationofXMLSignatureElements" shape="rect">Computation of XML Signature
|
|
Elements</a> in XKMS Messages</h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_61" id="XKMS_2_0_Paragraph_61" class="markParagraph" shape="rect">[61]</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="/TR/2005/REC-xkms2-20050628/#XKMS_2_0_Section_7_1_4" shape="rect">7.1.4</a> and <a href="/TR/2005/REC-xkms2-20050628/#XKMS_2_0_Section_7_1_6" shape="rect">7.1.6</a>
|
|
respectively, and the signature validation processing described in XKMS,
|
|
section <a href="/TR/2005/REC-xkms2-20050628/#XKMS_2_0_Section_3_1_2" shape="rect">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="XKMS_2_0_Section_3_4" id="XKMS_2_0_Section_3_4" shape="rect">3.4</a> <a name="UseofSOAPFaults" id="UseofSOAPFaults" shape="rect">Use of SOAP Faults</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_62" id="XKMS_2_0_Paragraph_62" class="markParagraph" shape="rect">[62]</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="XKMS_2_0_Section_3_4_1" id="XKMS_2_0_Section_3_4_1" shape="rect">3.4.1</a> <a name="SOAP12Faults" id="SOAP12Faults" shape="rect">SOAP 1.2 Faults</a></h3>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_63" id="XKMS_2_0_Paragraph_63" class="markParagraph" shape="rect">[63]</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="XKMS_2_0_Paragraph_64" id="XKMS_2_0_Paragraph_64" class="markParagraph" shape="rect">[64]</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="XKMS_2_0_Paragraph_65" id="XKMS_2_0_Paragraph_65" class="markParagraph" shape="rect">[65]</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:space="preserve"><?xml version="1.0" ?>
|
|
|
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/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="XKMS_2_0_Section_3_4_2" id="XKMS_2_0_Section_3_4_2" shape="rect">3.4.2</a> <a name="SOAP11Faults" id="SOAP11Faults" shape="rect">SOAP 1.1 Faults</a></h3>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_66" id="XKMS_2_0_Paragraph_66" class="markParagraph" shape="rect">[66]</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="XKMS_2_0_Paragraph_67" id="XKMS_2_0_Paragraph_67" class="markParagraph" shape="rect">[67]</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
|
|
"1". 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="XKMS_2_0_Paragraph_68" id="XKMS_2_0_Paragraph_68" class="markParagraph" shape="rect">[68]</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:space="preserve"><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/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="XKMS_2_0_Section_3_5" id="XKMS_2_0_Section_3_5" shape="rect">3.5</a> <a name="SOAPoverHTTPbinding" id="SOAPoverHTTPbinding" shape="rect">SOAP over HTTP
|
|
binding</a></h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_69" id="XKMS_2_0_Paragraph_69" class="markParagraph" shape="rect">[69]</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="XKMS_2_0_Paragraph_70" id="XKMS_2_0_Paragraph_70" class="markParagraph" shape="rect">[70]</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="XKMS_2_0_Section_4" id="XKMS_2_0_Section_4" shape="rect">4</a> <a name="SecurityBindings" id="SecurityBindings" shape="rect">Security Bindings</a></h1>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_71" id="XKMS_2_0_Paragraph_71" class="markParagraph" shape="rect">[71]</a>This specification describes two principal
|
|
security bindings each of which specifies two or more specific implementation
|
|
profiles.</p>
|
|
|
|
<table border="1" width="100%" id="AutoNumber1" cellspacing="0" cellpadding="4">
|
|
<thead>
|
|
<tr>
|
|
<th align="center" >Feature</th>
|
|
<th width="30%" >Payload Security</th>
|
|
<th width="30%" >Transaction Layer Security</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<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="XKMS_2_0_Section_4_1" id="XKMS_2_0_Section_4_1" shape="rect">4.1</a> <a name="PayloadAuthenticationBinding" id="PayloadAuthenticationBinding" shape="rect">Payload
|
|
Authentication Binding</a></h2>
|
|
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_71a" id="XKMS_2_0_Paragraph_71a" class="markParagraph" shape="rect">[71a]</a></p>
|
|
<dl>
|
|
<dt>Client Authentication Modes:</dt>
|
|
<dd>No mechanism is used to authenticate the client</dd>
|
|
<dd>The client is authenticated using payload security</dd>
|
|
</dl>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_71b" id="XKMS_2_0_Paragraph_71b" class="markParagraph" shape="rect">[71b]</a>In the following table, Request/Signature means that a XKMS Request
|
|
element includes a <code><dsig:Signature></code> element in enveloped
|
|
mode. This signature is calculated using a digital signature method.
|
|
Request/MAC has similar meaning, except that the signature is calculated
|
|
using a Message Authentication Code (MAC).</p>
|
|
|
|
<table border="1" cellpadding="4" cellspacing="0" width="100%" id="AutoNumber8">
|
|
<thead>
|
|
<tr>
|
|
<th width="45%" >Security Consideration</th>
|
|
<th width="5%" >Client Authentication
|
|
Mode</th>
|
|
<th width="15%" >Support</th>
|
|
<th >Comment</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<th width="45%" align="left" rowspan="2"><span style="font-weight: 400">Client
|
|
Authentication Mechanism</span></th>
|
|
<td width="5%" align="left" valign="top" >No
|
|
authentication mechanism is used.</td>
|
|
<td width="15%" align="center" >None</td>
|
|
<td > </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="5%" align="left" valign="top" >Authentication using payload
|
|
security</td>
|
|
<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>
|
|
<td width="5%" align="left" valign="top" > Not
|
|
Applicable</td>
|
|
<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>
|
|
<td width="5%" align="left" valign="top" >Authentication using payload
|
|
security</td>
|
|
<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>
|
|
<td width="5%" align="left" valign="top" >Any</td>
|
|
<td width="15%" align="center" >Payload</td>
|
|
<td >Message/Nonce in Two-phase protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th width="45%" align="left" ><span style="font-weight: 400">Denial Of
|
|
Service Protection</span></th>
|
|
<td width="5%" align="left" valign="top" >Any</td>
|
|
<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>
|
|
<td width="5%" align="left" valign="top" >Any</td>
|
|
<td width="15%" align="center" >Payload</td>
|
|
<td >Message/Signature with digital signature</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p></p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_72" id="XKMS_2_0_Paragraph_72" class="markParagraph" shape="rect">[72]</a> The following payload security features are
|
|
employed:</p>
|
|
|
|
<table border="1" cellpadding="4" cellspacing="0" width="100%" id="AutoNumber9">
|
|
<thead>
|
|
<tr>
|
|
<th width="50%" >XKMS element.attribute name</th>
|
|
<th width="50%" >Required</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.Service</td>
|
|
<td width="50%" >Required</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.Signature</td>
|
|
<td width="50%" >Required in profile where client is
|
|
authenticated using payload security for both Request and Response
|
|
Messages</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td width="50%" align="left" >ResultType.RequestId</td>
|
|
<td width="50%" >Required</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >PendingRequestType.ResponseId</td>
|
|
<td width="50%" >Required</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.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">MessageAbstractType.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.Signature
|
|
with MAC</td>
|
|
<td width="50%" >Required in profile where no
|
|
mechanism is used to authenticate the client, Optional in
|
|
profile where client is authenticated using
|
|
payload security</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2><a name="XKMS_2_0_Section_4_2" id="XKMS_2_0_Section_4_2" shape="rect">4.2</a> <a name="SecureSocketLayerandTransactionLayer" id="SecureSocketLayerandTransactionLayer" shape="rect">Secure Socket Layer and Transaction
|
|
Layer</a> (SSL/TLS)Security Binding</h2>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_73" id="XKMS_2_0_Paragraph_73" class="markParagraph" shape="rect">[73]</a>When TLS is to be used in XKMS, XKMS responders
|
|
MUST support server authenticated TLS. Note that this means that an XKMS
|
|
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 clear="none" />
|
|
<br clear="none" />
|
|
All XKMS clients and responders which support TLS MUST support the
|
|
TLS_RSA_WITH_3DES-EDE_CBC_SHA ciphersuite.<br clear="none" />
|
|
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="XKMS_2_0_Paragraph_74" id="XKMS_2_0_Paragraph_74" class="markParagraph" shape="rect">[74]</a>The SSL/TLS binding has three client authentication
|
|
modes:</p>
|
|
|
|
|
|
<dl>
|
|
<dt>SSL/TLS Client Authentication Modes:</dt>
|
|
<dd>No mechanism is used to authenticate the client</dd>
|
|
<dd>TLS certificate based client authentication is used to authenticate
|
|
the client</dd>
|
|
<dd>Payload security is used for client authentication</dd>
|
|
</dl>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_74a" id="XKMS_2_0_Paragraph_74a" class="markParagraph" shape="rect">[74a]</a></p>
|
|
|
|
<table border="1" cellpadding="4" cellspacing="0" width="100%" id="AutoNumber6">
|
|
<thead>
|
|
<tr>
|
|
<th width="25%" >Security Consideration</th>
|
|
<th width="15%" >Client
|
|
Authentication Mode</th>
|
|
<th width="15%" >Support</th>
|
|
<th >Comment</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td width="25%" align="left" rowspan="3" >Client Authentication Mechanism</td>
|
|
<td width="15%" >No authentication mechanism is used
|
|
</td>
|
|
<td width="15%" align="center" >None</td>
|
|
<td width="45%" > </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%" >TLS certificate based client
|
|
authentication is used.</td>
|
|
<td width="15%" align="center" >TLS</td>
|
|
<td width="45%" >Certificate based client authentication</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%" >Authentication using Payload
|
|
security</td>
|
|
<td width="15%" align="center" >Payload</td>
|
|
<td width="45%" >Request/Signature</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="25%" align="left" >Service Authentication Mechanism</td>
|
|
<td width="15%" >Not applicable</td>
|
|
<td width="15%" align="center" >TLS</td>
|
|
<td width="45%" > </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="25%" align="left" >Request/Response Correspondence</td>
|
|
<td width="15%" >Any</td>
|
|
<td width="15%" align="center" >TLS</td>
|
|
<td width="45%" >Message/RequestId</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="25%" align="left" >Replay Attack Protection</td>
|
|
<td width="15%" >Any</td>
|
|
<td width="15%" align="center" >TLS</td>
|
|
<td width="45%" >Message/Nonce in Two-phase protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="25%" align="left" >Denial Of Service Protection</td>
|
|
<td width="15%" >Any</td>
|
|
<td width="15%" align="center" >None</td>
|
|
<td width="45%" >TLS has no specific countermeasures against denial of service
|
|
attacks</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="25%" align="left" >Non Repudiation</td>
|
|
<td width="15%" >Any</td>
|
|
<td width="15%" align="center" >Payload</td>
|
|
<td width="45%" >Message/Signature with digital signature [if
|
|
required]</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p></p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_75" id="XKMS_2_0_Paragraph_75" class="markParagraph" shape="rect">[75]</a> The following payload security features are
|
|
employed:</p>
|
|
|
|
<table border="1" cellpadding="4" cellspacing="0" width="100%" id="AutoNumber7">
|
|
<thead>
|
|
<tr>
|
|
<th width="50%" >XKMS element.attribute name</th>
|
|
<th width="50%" >Required</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.Service</td>
|
|
<td width="50%" >Required, but not dependent</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.Signature</td>
|
|
<td width="50%" >Optional, may be used to support non-repudiation for
|
|
both Request and Response messages</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >ResultType.RequestId</td>
|
|
<td width="50%" >Required, but not dependent</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >PendingRequestType.ResponseId</td>
|
|
<td width="50%" >Required, but not dependent</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" >MessageAbstractType.Nonce</td>
|
|
<td width="50%" >Unnecessary</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="50%" align="left" ><span class="c11">MessageAbstractType.RespondWith=Represent</span></td>
|
|
<td width="50%" >Unnecessary</td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
|
|
<h1 class="appendix"><a name="XKMS_2_0_Section_Appendix_A" id="XKMS_2_0_Section_Appendix_A" shape="rect">Appendix A</a> <a name="References" id="References" shape="rect">References (Non-Normative)</a></h1>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_76" id="XKMS_2_0_Paragraph_76" class="markParagraph" shape="rect">[76]</a> <b><a name="ref-KEYWORDS" id="ref-KEYWORDS" shape="rect">[RFC2119]</a></b> S. Bradner, <i>Key words for use in RFCs
|
|
to Indicate Requirement Levels</i>, IETF RFC 2119, March 1997. <a href="http://www.ietf.org/rfc/rfc2119.txt" shape="rect">http://www.ietf.org/rfc/rfc2119.txt</a>.</p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_77" id="XKMS_2_0_Paragraph_77" class="markParagraph" shape="rect">[77]</a> <b><a id="TLS" name="TLS" shape="rect">[RFC2246]</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" shape="rect">http://www.ietf.org/rfc/rfc2246.txt</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_78" id="XKMS_2_0_Paragraph_78" class="markParagraph" shape="rect">[78]</a> <b><a name="RFC2693" id="RFC2693" shape="rect">[RFC2693]</a></b> C. Ellison et. al., Simple Public Key
|
|
Infrastructure Certificate Theory, IETF RFC 2693, Sept. 1999. <a href="http://www.ietf.org/rfc/rfc2693.txt" shape="rect">http://www.ietf.org/rfc/rfc2693.txt</a> </p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_79" id="XKMS_2_0_Paragraph_79" class="markParagraph" shape="rect">[79]</a> <b>[<a name="RFC3280" id="RFC3280" shape="rect">RFC3280</a>]</b> R. Housley et. al., Public Key Infrastructure
|
|
(X.509) (PKIX) Certificate and Certificate Revocation List (CRL) Profile,
|
|
IETF RFC 3280, April 2002 ,<a href="http://www.ietf.org/rfc/rfc3280.txt" shape="rect">http://www.ietf.org/rfc/rfc3280.txt</a> </p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_80" id="XKMS_2_0_Paragraph_80" class="markParagraph" shape="rect">[80]</a> <b>[<a id="SOAP" name="SOAP" shape="rect">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/2000/NOTE-SOAP-20000508/" shape="rect">http://www.w3.org/TR/2000/NOTE-SOAP-20000508/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_81" id="XKMS_2_0_Paragraph_81" class="markParagraph" shape="rect">[81]</a> <b><a id="XMLP-1" name="XMLP-1" shape="rect">[SOAP1.2-1]</a></b> M. Gudgin, et al. <i>SOAP Version 1.2
|
|
Part 1: Messaging Framework</i>, W3C Recommendation 24 June 2003. <a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/" shape="rect">http://www.w3.org/TR/2003/REC-soap12-part1-20030624/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_82" id="XKMS_2_0_Paragraph_82" class="markParagraph" shape="rect">[82]</a> <b><a id="XMLP-2" name="XMLP-2" shape="rect">[SOAP1.2-2]</a></b> M. Gudgin, et al. <i>SOAP Version 1.2
|
|
Part 2: Adjuncts</i>, W3C Recommendation 24 June 2003. <a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/" shape="rect">http://www.w3.org/TR/2003/REC-soap12-part2-20030624/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_85" id="XKMS_2_0_Paragraph_85" class="markParagraph" shape="rect">[85]</a> <b>[<a id="XML-SIG" name="XML-SIG" shape="rect">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>,
|
|
W3C Recommendation. <a href="http://www.w3.org/TR/xmldsig-core/" shape="rect">http://www.w3.org/TR/xmldsig-core/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_86" id="XKMS_2_0_Paragraph_86" class="markParagraph" shape="rect">[86]</a> <b>[<a id="XML-SIG-XSD" name="XML-SIG-XSD" shape="rect">XML-SIG-XSD</a>]</b> XML Signature Schema available from
|
|
<a href="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd" shape="rect">http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_86a" id="XKMS_2_0_Paragraph_86a" class="markParagraph" shape="rect">[86a]</a> <b>[<a id="XML-EXC-C14N" name="XML-EXC-C14N" shape="rect">XML-EXC-C14N</a>]</b> J. Boyer, D. E. Eastlake, J. Reagle. <em>Exclusive XML Canonicalization</em>. W3C Recommendation 8 July 2002.
|
|
<a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/" shape="rect">http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_87" id="XKMS_2_0_Paragraph_87" class="markParagraph" shape="rect">[87]</a> <b>[<a id="XML-Enc" name="XML-Enc" shape="rect">XML-Enc</a>]</b> D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E. Simon, <i>XML Encryption Syntax and
|
|
Processing</i>, W3C Recommendation 10 December 2002. <a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/" shape="rect">http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_88" id="XKMS_2_0_Paragraph_88" class="markParagraph" shape="rect">[88]</a> <b>[<a id="ref-XML-NS" name="ref-XML-NS" shape="rect">XML-NS</a>]</b> 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/" shape="rect">http://www.w3.org/TR/1999/REC-xml-names-19990114</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_89" id="XKMS_2_0_Paragraph_89" class="markParagraph" shape="rect">[89]</a> <b>[<a id="XML-Schema1" name="XML-Schema1" shape="rect">XML-Schema1</a>]</b> H. S. Thompson, D. Beech, M. Maloney,
|
|
N. Mendelsohn. <i>XML Schema Part 1: Structures Second Edition</i>, W3C Recommendation 28 October 2004. <a href="http://www.w3.org/TR/xmlschema-1/" shape="rect">http://www.w3.org/TR/xmlschema-1/</a></p>
|
|
|
|
<p class="Ref"><a name="XKMS_2_0_Paragraph_90" id="XKMS_2_0_Paragraph_90" class="markParagraph" shape="rect">[90]</a> <b>[<a id="XML-Schema2" name="XML-Schema2" shape="rect">XML-Schema2</a>]</b> P. V. Biron, A. Malhotra, <i>XML
|
|
Schema Part 2: Datatypes Second Edition</i>; W3C Recommendation 28 October 2004. <a href="http://www.w3.org/TR/xmlschema-2/" shape="rect">http://www.w3.org/TR/xmlschema-2/</a></p>
|
|
|
|
<h1 class="appendix"><a name="XKMS_2_0_Section_Appendix_B" id="XKMS_2_0_Section_Appendix_B" shape="rect">Appendix B</a> <a name="Acknowledgments" id="Acknowledgments" shape="rect">Acknowledgments (Non-Normative)</a></h1>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_91" id="XKMS_2_0_Paragraph_91" class="markParagraph"
|
|
shape="rect">[91]</a>This specification is the work of the W3C XML Key Management
|
|
Working Group. 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"
|
|
shape="rect">contributor policies</a> and the active <a
|
|
href="http://www.w3.org/2001/XKMS/Participants.html" shape="rect">WG
|
|
roster</a>.</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_92" id="XKMS_2_0_Paragraph_92" class="markParagraph"
|
|
shape="rect">[92]</a>Participants in the Working Group are (at the time of writing, and
|
|
by alphabetical order): Guillermo Alvaro Rey (Trinity College
|
|
Dublin), Stephen Farrell (Trinity College Dublin, Co-Chair),
|
|
José Kahan (W3C, staff contact), Berin Lautenbach (Apache
|
|
Software Foundation), Tommy Lindberg (Markup Security), Roland
|
|
Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram
|
|
Mysore (Co-Chair; Editor since 13 Apr 2004), Rich Salz (DataPower
|
|
Technology, Inc.), Yunhao Zhang (SQLData Systems).</p>
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_93" id="XKMS_2_0_Paragraph_93" class="markParagraph"
|
|
shape="rect">[93]</a>Previous participants
|
|
were (by alphabetical order): Daniel Ash (Identrus),
|
|
Blair Dillaway (Microsoft), Donald
|
|
Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods),
|
|
Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, Editor until 13 Apr 2004),
|
|
Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore),
|
|
Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat),
|
|
Brian LaMacchia (Microsoft), Pradeep Lamsal,
|
|
Joseph Reagle (W3C, previous staff contact), Dave Remy (GeoTrust, Inc.), Peter
|
|
Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)</p>
|
|
|
|
|
|
<p><a name="XKMS_2_0_Paragraph_94" id="XKMS_2_0_Paragraph_94" class="markParagraph"
|
|
shape="rect">[94]</a>The authors also acknowledge
|
|
the extensive assistance provided in
|
|
the design stage of this specification by David Solo (CitiGroup) and
|
|
Barbara Fox (Microsoft), and the contributions of (by alphabetical
|
|
order) Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes,
|
|
Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei
|
|
(VeriSign).</p>
|
|
|
|
<h1 class="appendix"><a name="XKMS_2_0_Section_Appendix_C" id="XKMS_2_0_Section_Appendix_C" shape="rect">Appendix C Changes (Non-Normative)</a></h1>
|
|
|
|
<p>This appendix documents changes (other than very minor editorial
|
|
changes) from the <a
|
|
href="http://www.w3.org/TR/2005/PR-xkms2-bindings-20050502/">Proposed
|
|
Recommendation of 2 May 2005</a> that were made to accommodate the <a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html">comments</a>. Each
|
|
entry contains:</p>
|
|
<ul>
|
|
<li>a change number</li>
|
|
<li>a brief description and, where appropriate, what has been done about
|
|
it</li>
|
|
<li>a link to the message causing the change (if the message is public)</li>
|
|
</ul>
|
|
|
|
<h2><a name="XKMS_2_0_Section_Appendix_C_1" id="XKMS_2_0_Section_Appendix_C_1" shape="rect">Changes in the XKMS Bindings Specification between PR and Recommendation</a></h2>
|
|
<ol>
|
|
<li>
|
|
Change. The text in p. [60] was confusing on how to avoid
|
|
namespace prefix collisions when embedding XKMS messages in SOAP
|
|
documents. This was changed to say that the XKMS messages SHOULD
|
|
be signed using exc-c14n, and which was already suggested by
|
|
pp. [89] and [90] of the XKMS specification.
|
|
(<a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#345-ml"
|
|
shape="rect">345-ml</a>)
|
|
</li>
|
|
<li>
|
|
Correction. pp. 46, 47, 55, 56 of Part 2 incorrectly indicated that the SOAP
|
|
Body resides inside the SOAP Header. (<a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#338-tl-1"
|
|
shape="rect">338-tl-1</a>)</li>
|
|
<li>
|
|
Correction. p. 47 had a redundant semicolon (;) at the end.
|
|
(<a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#338-tl-2"
|
|
shape="rect">338-tl-2</a>)</li>
|
|
<li>
|
|
Correction. Clarified p. 43 to say that XKMS messages are carried in Soap 1.2
|
|
messages as literal Body element content. Removed the
|
|
rationale of why encoding was not selected as it had become irrelevant.
|
|
(<a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#339-ml"
|
|
shape="rect">339-ml</a>)
|
|
</li>
|
|
<li>
|
|
Correction. Clarified p. 53 to say that XKMS messages are carriend in Soap 1.1
|
|
messages as literal Body element content.
|
|
(<a
|
|
href="http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#348-ml"
|
|
shape="rect">348-ml</a>)
|
|
</li>
|
|
</ol>
|
|
|
|
<p></p>
|
|
|
|
</body>
|
|
</html>
|