ghopp
/
server_playground
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Another abandoned server code base... this is kind of an ancestor of taskrambler.
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.
146 Commits
1 Branch
0 Tags
51 MiB
 
 
 
 
 
 
Tree: e7553ea218
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'e7553ea218'
${ noResults }
server_playground/doc/www.w3.org/TR/2002/CR-xml-exc-c14n-20020212

901 lines
35 KiB
Raw Blame History

<?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>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Exclusive XML Canonicalization Version 1.0</title>
<style type="text/css">
u,ins { background: white; color: red;}
del,strike,.strike { background: white; color: silver; text-decoration: line-through;}
code {font-weight: normal; }
.link-def { background: #FFFFFF; color: teal; font-style: italic;}
.comment { background: #FFFFF5; color: black; padding: .7em; border:
navy thin solid;}
.discuss { color: blue; background: yellow; }
.xml-example,.xml-dtd { margin-left: -1em; padding: .5em; white-space:
pre; border: none;}
.xml-dtd { background: #efeff8; color: black;}
</style>
<link href="http://www.w3.org/StyleSheets/TR/W3C-CR"
type="text/css" rel="stylesheet" />
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1" />
</head>
<body xml:lang="en" lang="en">
<p><a href="http://www.w3.org/"><img
src="http://www.w3.org/Icons/w3c_home" alt="W3C" border="0"
height="48" width="72" /></a></p>
<div class="head">
<h1 class="notoc">Exclusive XML Canonicalization<br />
Version 1.0</h1>
<h2 class="notoc">W3C Candidate Recommendation 12 February
2002</h2>
<dl>
<dt>This version:</dt>
<dd><a
href="http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212">http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212</a></dd>
<dt>Latest version:</dt>
<dd><a
href="http://www.w3.org/TR/xml-exc-c14n">http://www.w3.org/TR/xml-exc-c14n</a></dd>
<dt>Previous version:</dt>
<dd><a
href="http://www.w3.org/TR/2001/WD-xml-exc-c14n-20011120">http://www.w3.org/TR/2001/WD-xml-exc-c14n-20011120</a></dd>
<dt>Authors/Editors:</dt>
<dd>John Boyer, PureEdge Solutions Inc., <a
href="mailto:jboyer@PureEdge.com">jboyer@PureEdge.com</a></dd>
<dd>Donald E. Eastlake 3rd, Motorola, <a
href="mailto:Donald.Eastlake@motorola.com">Donald.Eastlake@Motorola.com</a></dd>
<dd>Joseph Reagle, W3C, <a
href="mailto:reagle@w3.org">reagle@w3.org</a></dd>
</dl>
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
Copyright</a> &copy; 2002 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup>
(<a href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
title="Institut National de Recherche en Informatique et Automatique">
INRIA</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-20000612#Legal_Disclaimer">
liability</a>, <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
trademark</a>, <a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
document use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
software licensing</a> rules apply.</p>
<hr title="Separator from Header" />
</div>
<h2 class="notoc">Abstract</h2>
<p>Canonical XML [<a href="#ref-XML-C14N">XML-C14N</a>] specifies a
standard serialization of XML that, when applied to a subdocument,
includes the subdocument's ancestor context including all of the
namespace declarations and attributes in the "xml:" namespace.
However, some applications require a method which, to the extent
practical, excludes unused ancestor context from a canonicalized
subdocument. For example, one might require a digital signature
over an XML payload (subdocument) in an XML message that will not
break when that subdocument is removed from its original message
and/or inserted into a different context. This requirement is
satisfied by Exclusive XML Canonicalization.</p>
<h2><a id="status" name="status">Status of this document</a></h2>
<div class="">
<p>This specification from the IETF/W3C <a
href="http://www.w3.org/Signature/">XML Signature Working Group</a>
(<a href="http://www.w3.org/Signature/Activity.html">W3C Activity
Statement</a>) is a <a class="loc"
href="http://www.w3.org/Consortium/Process/Process-19991111/process.html#RecsCR">
Candidate Recommendation</a> of the W3C. The Working Group believes
this specification incorporates the resolution of all <a
href="http://www.w3.org/Signature/2002/01/last-call-issues.html">last
call issues</a>; furthermore it considers the specification to be
very stable and invites implementation feedback during this
period.</p>
<p class="notoc">The exit criteria for this phase is atleast two
interoperable implementations over every feature, one
implementation of all features, and one report of satisfaction in
an application context (e.g., SOAP, SAML, etc.) Note, this
specification already has significant implementation experience as
demonstrated by its <a
href="http://www.w3.org/Signature/2002/02/01-exc-c14n-interop.html">
Interoperability Report</a>. We expect to meet all requirements of
that report within the two month Candidate Recommendation period
(closing April 16). Specific areas where we would appreciate
further implementation experience are:</p>
<ol>
<li>
<p class="notoc">Speed of canonicalziation relative to Canonical
XML; <a
href="http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0108.html">
it should be no slower, is it faster</a>?</p>
</li>
<li>Use in application contexts. Does the specified behaviour meet
application requirements for flexibly canonicalizing document
subsets if they are moved out of their context? For example, <a
href="http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0048.html">
does your application scenario lead to any difficulties in which a
subset (e.g., payload) require the use of an ancestor base that is
not easily remedied by including xml:base in the apex of the
subset?</a></li>
</ol>
<p>Please send comments to the editors and cc: the list &lt;<a
href="mailto:w3c-ietf-xmldsig@w3.org">w3c-ietf-xmldsig@w3.org</a>&gt;.</p>
<p>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>Patent disclosures relevant to this specification may be found
on the Working Group's <a
href="http://www.w3.org/Signature/Disclosures.html">patent
disclosure page</a> in conformance with W3C policy, and the <a
href="http://www.ietf.org/ipr.html">IETF Page of Intellectual
Property Rights Notices</a> in conformance with IETF policy.</p>
</div>
<h2><a id="contents" name="contents">Table of Contents</a></h2>
<ol>
<li><a href="#sec-Intro">Introduction</a>
<ol>
<li><a href="#sec-Terminology">Terminology</a></li>
<li><a href="#sec-Applications">Applications</a></li>
<li><a href="#sec-Limitations">Limitations</a></li>
</ol>
</li>
<li><a href="#sec-ExclusiveNeed">The Need for Exclusive XML
Canonicalization</a>
<ol>
<li><a href="#sec-Simple">A Simple Example</a></li>
<li><a href="#sec-Enveloping">General Problems with Enveloping and
de-Enveloping</a></li>
</ol>
</li>
<li><a href="#sec-Specification">Specification of Exclusive XML
Canonicalization</a></li>
<li><a href="#sec-Use">Use in XML Security</a></li>
<li><a href="#sec-Considerations">Security Considertions</a></li>
<li><a href="#sec-References">References</a></li>
<li><a href="#sec-Acknowledgements">Acknowledgements</a></li>
</ol>
<hr />
<!-- =============================================================================== -->
<h2><a id="sec-Intro" name="sec-Intro"></a>1. Introduction</h2>
<p>The XML Recommendation <a href="#ref-XML">[XML]</a> specifies
the syntax of a class of objects called XML documents. The Names in
XML Recommendation [<a href="#ref-XML-NS">XML-NS</a>] specifies
additional syntax and semantics for XML documents. It is normal for
XML documents and subdocuments which are equivalent for the
purposes of many applications to differ in their physical
representation. For example, they may differ in their entity
structure, attribute ordering, and character encoding. The goal of
this specification is to establish a method for serializing the
XPath node set representation of an XML document or subset such
that:</p>
<ol>
<li>The node set is minimally affected by any XML context which has
been omitted.</li>
<li>The canonicalization of a nodeset representing <a
href="http://www.w3.org/TR/2001/CR-xml-fragment-20010212#defn-well-balanced">
well-balanced</a> XML [<a
href="#ref-XML-Fragment">XML-Fragment</a>] will be unaltered by
further applications of exclusive canonicalization.</li>
<li>It can be determined whether two node sets are identical except
for transformations considered insignificant by this specification
under [<a href="#ref-XML">XML</a>,<a
href="#ref-XML-NS">XML-NS</a>].</li>
</ol>
<p>An understanding of the Canonical XML Recommendation [<a
href="#ref-XML-C14N">XML-C14N</a>] is required.</p>
<h3><a id="sec-Terminology" name="sec-Terminology">1.1
Terminology</a></h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119 <a
href="#ref-Keywords">[Keywords]</a>.</p>
<p>The XPath 1.0 Recommendation <a href="#ref-XPath">[XPath]</a>
defines the term <a class="link-def" name="def-node-set"
id="def-node-set">node-set</a> and specifies a data model for
representing an input XML document as a set of nodes of various
types (element, attribute, namespace, text, comment, processing
instruction, and root). The nodes are included in or excluded from
a node-set based on the evaluation of an expression. Within this
specification and [<a href="#ref-XML-C14N">XML-C14N</a>], a
node-set is used to directly indicate whether or not each node
should be rendered in the canonical form (in this sense, it is used
as a formal mathematical set). A node that is excluded from the set
is not rendered in the canonical form being generated, even if its
parent node is included in the node-set. However, an omitted node
may still impact the rendering of its descendants (e.g. by
affecting the namespace context of the descendants).</p>
<p>A <a class="link-def" name="def-document-subset"
id="def-document-subset">document subset</a> is a portion of an XML
document indicated by an XPath node-set that may not include all of
the nodes in the document. An <a class="link-def"
name="def-apex-node" id="def-apex-node">apex node</a> is an element
node in a document subset having no element node ancestor in the
document subset. An <a class="link-def" name="def-orphan-node"
id="def-orphan-node">orphan node</a> is an element node whose
parent element node is not in the document subset. The <a
class="link-def" name="def-output-parent"
id="def-output-parent">output parent</a> of an orphan node that is
not an apex node is the nearest ancestor element of the orphan node
that is in the document subset; an <a href="#def-apex-node"
class="link-def">apex node</a> has no <a href="#def-output-parent"
class="link-def">output parent</a>. The output parent of a
non-orphan node is the parent of the node. An <a class="link-def"
name="def-output-ancestor" id="def-output-ancestor">output
ancestor</a> is any ancestor element node in the document
subset.</p>
<p>For example in a document tree with three generations under the
root node <code>A</code> and where capitalization denotes the node
is in the document subset (<code>A,E,G</code>):</p>
<pre>
A-+-b
`-c-+-d
`-E-+-f
`-G
</pre>
<ul>
<li><code>A</code> is an apex node, output parent of
<code>E</code>, and output ancestor of (<code>E,G</code>);</li>
<li><code>E</code> is an orphan node and the output parent of
<code>G.</code></li>
</ul>
<p>An element <em>E</em> in a document subset <a class="link-def"
name="def-visibly-utilizes" id="def-visibly-utilizes">visibly
utilizes</a> a namespace declaration, i.e. a namespace prefix
<em>P</em> and bound value <em>V</em>, if <em>E</em> or an
attribute node in the document subset with parent <em>E</em> has a
qualified name in which <i>P</i> is the namespace prefix. A similar
definition applies for an element E in a document subset that <a
class="link-def" href="#def-visibly-utilizes">visibly utilizes</a>
the default namespace declaration, which occurs if <em>E</em> has
no namespace prefix</p>
<p>The namespace axis of an element contains nodes for all
non-default namespace declarations made within the element as well
as non-default namespace declarations inherited from ancestors of
the element. The namespace axis also contains a node representing
the default namespace if it is not the empty string, whether the
default namespace was declared within the element or by an ancestor
of the element. Any subset of the nodes in a namespace axis can be
included in a document subset.</p>
<p>The method of canonicalization described in this specification
receives an <a class="link-def"
name="def-InclusiveNamespaces-PrefixList"
id="def-InclusiveNamespaces-PrefixList">InclusiveNamespaces
PrefixList</a> parameter, which lists namespace prefixes that are
handled in the manner described by the Canonical XML Recommendation
[<a href="#ref-XML-C14N">XML-C14N</a>].</p>
<p>The <a class="link-def" name="def-exclusive-canonical-form"
id="def-exclusive-canonical-form">exclusive canonical form</a> of a
document subset is a physical representation of the XPath node-set,
that is an octet sequence, produced by the method described in this
specification. It is as defined in the Canonical XML Recommendation
[<a href="#ref-XML-C14N">XML-C14N</a>] except for the changes
summarized as follows:</p>
<ul>
<li>attributes in the XML namespace, such as <code>xml:lang</code>
and <code>xml:space</code> are not imported into orphan nodes of
the document subset, and</li>
<li>namespace nodes that are not on the <a class="link-def"
href="#def-InclusiveNamespaces-PrefixList">InclusiveNamespaces
PrefixList</a> are expressed only in start tags where they are
visible and if they are not in effect from an <a class="link-def"
href="#def-output-ancestor">output ancestor</a> of that tag</li>
</ul>
<p>The term <a class="link-def" name="def-exclusive-canonical-XML"
id="def-exclusive-canonical-XML">exclusive canonical XML</a> refers
to XML that is in exclusive canonical form. The <a class="link-def"
name="def-exclusive-XML-canonicalization-method"
id="def-exclusive-XML-canonicalization-method">exclusive XML
canonicalization method</a> is the algorithm defined by this
specification that generates the exclusive canonical form of a
given XML document subset. The term <a class="link-def"
name="def-exclusive-XML-canonicalization"
id="def-exclusive-XML-canonicalization">exclusive XML
canonicalization</a> refers to the process of applying the
exclusive XML canonicalization method to an XML document
subset.</p>
<h3><a id="sec-Applications" name="sec-Applications">1.2
Applications</a></h3>
<p>The applications of Exclusive XML Canonicalization are very
similar to those for Canonical XML [<a
href="#ref-XML-C14N">XML-C14N</a>]. However, exclusive
canonicalization, or equivalent means of excluding most XML
context, is necessary for signature applications where the XML
context of signed XML will change. This sort of change is typical
of many protocol applications.</p>
<p>Note that in the case of the <code>SignedInfo</code> element of
[<a href="#ref-XML-DSig">XML-DSig</a>], the specification of an
appropriate canonicalization method is the only technique available
to protect the signature from insignificant changes in physical
form and changes in XML context.</p>
<h3><a id="sec-Limitations" name="sec-Limitations">1.3
Limitations</a></h3>
<p>Exclusive XML Canonicalization has the limitations of Canonical
XML [<a href="#ref-XML-C14N">XML-C14N</a>] plus two additional
limitations as follows:</p>
<ol>
<li>The XML being canonicalized may depend on the effect of xml
namespace attributes, such as <code>xml:lang</code> and
<code>xml:space</code>, appearing in ancestor nodes. To avoid
problems due to the non-importation of such attributes into an
enveloped document subset, either they must be explicitly given in
the apex nodes of the XML document subset being canonicalized or
they must always be declared with an equivalent value in every
context in which the XML document subset will be interpreted.</li>
<li>The XML being canonicalized may depend on the effect of XML
namespace declarations where the namespace prefix being bound is
not visibly utilized. An example would be an attribute whose value
is an XPath expression and whose evaluation therefore depends upon
namespace prefixes referenced in the expression. To avoid problems
with such namespace declarations,
<ul>
<li>the XML must be modified so that use of the namespace prefix
involved is visible or</li>
<li>the namespace declarations must appear and be bound to the same
values in every context in which the XML will be interpreted
or</li>
<li>the prefixes for such namespaces must appear in the
<i>InclusiveNamespaces PrefixList</i>.</li>
</ul>
</li>
</ol>
<!-- =============================================================================== -->
<h2><a id="sec-ExclusiveNeed" name="sec-ExclusiveNeed">2. The Need
for Exclusive XML Canonicalization</a></h2>
<p>In some cases, particularly for signed XML in protocol
applications, there is a need to canonicalize a subdocument in such
a way that it is substantially independent of its XML context. This
is because, in protocol applications, it is common to envelope XML
in various layers of message or transport elements, to strip off
such enveloping, and to construct new protocol messages, parts of
which were extracted from different messages previously received.
If the pieces of XML in question are signed, they need to be
canonicalized in a way such that these operations do not break the
signature but the signature still provides as much security as can
be practically obtained.</p>
<h3><a id="sec-Simple" name="sec-Simple">2.1 A Simple
Example</a></h3>
<p>As a simple example of the type of problem that changes in XML
context can cause for signatures, consider the following
document:</p>
<pre class="xml-example">
&lt;n1:elem1 xmlns:n1="http://b.example"&gt;
content
&lt;/n1:elem1&gt;
</pre>
<p>this is then enveloped in another document:</p>
<pre class="xml-example">
&lt;n0:pdu xmlns:n0="http://a.example"&gt;
&lt;n1:elem1 xmlns:n1="http://b.example"&gt;
content
&lt;/n1:elem1&gt;
&lt;/n0:pdu&gt;
</pre>
<p>The first document above is in canonical form. But assume that
document is enveloped as in the second case. The subdocument with
<code>elem1</code> as its apex node can be extracted from this
second case with an XPath expression such as</p>
<pre class="xml-example">
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]
</pre>
<p>The result of applying Canonical XML to the resulting XPath node
set is the following (except for line wrapping to fit this
document):</p>
<pre class="xml-example">
&lt;n1:elem1 xmlns:n0="http://a.example"
xmlns:n1="http://b.example"&gt;
content
&lt;/n1:elem1&gt;
</pre>
<p>Note that the <code>n0</code> namespace has been included by
Canonical XML because it includes namespace context. This change
which would break a signature over <code>elem1</code> based on the
first version.</p>
<h3><a id="sec-Enveloping" name="sec-Enveloping"></a>2.2 General
Problems with re-Enveloping</h3>
<p>As a more complete example of the changes in canonical form that
can occur when the enveloping context of a document subset is
changed, consider the following document:</p>
<pre class="xml-example">
&lt;n0:local xmlns:n0="foo:bar"
xmlns:n3="ftp://example.org"&gt;
&lt;n1:elem2 xmlns:n1="http://example.net"
xml:lang="en"&gt;
&lt;n3:stuff xmlns:n3="ftp://example.org"/&gt;
&lt;/n1:elem2&gt;
&lt;/n0:local&gt;
</pre>
<p>And the following which has been produced by changing the
enveloping of <code>elem2</code>:</p>
<pre class="xml-example">
&lt;n2:pdu xmlns:n1="http://example.com"
xmlns:n2="http://foo.example"
xml:lang="fr"
xml:space="retain"&gt;
&lt;n1:elem2 xmlns:n1="http://example.net"
xml:lang="en"&gt;
&lt;n3:stuff xmlns:n3="ftp://example.org"/&gt;
&lt;/n1:elem2&gt;
&lt;/n2:pdu&gt;
</pre>
<p>Assume an XPath node set produced from each case by applying the
following XPath expression</p>
<pre class="xml-example">
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2]
</pre>
<p>Applying Canonical XML to the node set produced from the first
document yields the following serialization (except for line
wrapping to fit in this document):</p>
<pre class="xml-example">
&lt;n1:elem2 xmlns:n0="foo:bar"
xmlns:n1="http://example.net"
xmlns:n3="ftp://example.org"
xml:lang="en"&gt;
&lt;n3:stuff&gt;&lt;/n3:stuff&gt;
&lt;/n1:elem2&gt;
</pre>
<p>However, although <code>elem2</code> is represented by the same
octet sequence in both pieces of external XML above, the Canonical
XML version of <code>elem2</code> from the second case would be
(except for line wrapping so it will fit into this document) as
follows:</p>
<pre class="xml-example">
&lt;n1:elem2 xmlns:n1="http://example.net"
xmlns:n2="http://foo.example"
xml:lang="en"
xml:space="retain"&gt;
&lt;n3:stuff xmlns:n3="ftp://example.org"&gt;&lt;/n3:stuff&gt;
&lt;/n1:elem2&gt;
</pre>
<p>Note that the change in context has resulted in lots of changes
in the subdocument as serialized by the inclusive Canonical XML [<a
href="#ref-XML-C14N">XML-C14N</a>]. In the first example,
<code>n0</code> had been included from the context and the presence
of an identical <code>n3</code> namespace declaration in the
context had elevated that declaration to the apex of the
canonicalized form. In the second example, <code>n0</code> has gone
away but <code>n2</code> has appeared, <code>n3</code> is no longer
elevated, and an <code>xml:space</code> declaration has appeared,
due to changes in context. But not all context changes have effect.
In the second example, the presence at ancestor nodes of an
<code>xml:lang</code> and <code>n1</code> prefix namespace
declaration have no effect because of existing declarations at the
<code>elem2</code> node.</p>
<p>On the other hand, using Exclusive XML Canonicalization as
specified herein, the physical form of <code>elem2</code> as
extracted by the XPath expression above is (except for line
wrapping so it will fit into this document) as follows:</p>
<pre class="xml-example">
&lt;n1:elem2 xmlns:n1="http://example.net"
xml:lang="en"&gt;
&lt;n3:stuff xmlns:n3="ftp://example.org"&gt;&lt;/n3:stuff&gt;
&lt;/n1:elem2&gt;
</pre>
<p>in both cases.</p>
<!-- =============================================================================== -->
<h2><a id="sec-Specification" name="sec-Specification"></a>3.
Specification of Exclusive XML Canonicalization</h2>
<p>The data model, processing, input parameters, and output data
for Exclusive XML Canonicalization are the same as for Canonical
XML [<a href="#ref-XML-C14N">XML-C14N</a>] with the following
exceptions:</p>
<ol>
<li>Canonical XML applied to a document subset requires the search
of the ancestor nodes of each orphan element node for attributes in
the xml namespace, such as <code>xml:lang</code> and
<code>xml:space</code>. These are copied into the element node
except if a declaration of the same attribute is already in the
attribute axis of the element (whether or not it is included in the
document subset). This search and copying are omitted from the
Exclusive XML Canonicalization method.</li>
<li>The Exclusive XML Canonicalization method may receive an
additional, possibly null, parameter <a class="link-def"
href="#def-InclusiveNamespaces-PrefixList">InclusiveNamespace-PrefixList</a>
containing a list of namespace prefixes and/or a token indicating
the presense of the default namespace. All namespace nodes
appearing on this list are handled as provided in Canonical XML [<a
href="#ref-XML-C14N">XML-C14N</a>].</li>
<li>For every namespace node with a prefix that does not appear in
the <a class="link-def"
href="#def-InclusiveNamespaces-PrefixList">InclusiveNamespacePrefix
List</a>, a namespace declaration is output at every output element
where that prefix is <a class="link-def"
href="#def-visibly-utilizes">visibly utilized</a> and that prefix
and its value <em>does not</em> appear in the nearest <a
href="#def-output-ancestor" class="link-def">output ancestor</a>
with the same prefix.</li>
</ol>
<p>One method (non-normative) for implementing the Exclusive XML
Canonicalization method is as follows:</p>
<ol>
<li>Recursively process the <strong>entire</strong> tree (from
which the XPath node-set was selected) in document order starting
with the root. (The operation of copying ancestor <code>xml:</code>
namespace attributes into output <a href="#def-apex-node"
class="link-def">apex element nodes</a> is <strong>not</strong>
done.)</li>
<li>If the node is not in the XPath subset, process its children
element nodes recursively.</li>
<li>If the element node is in the XPath subset then output the node
in accordance with Canonical XML except for namespace nodes which
are rendered as follows:
<ol>
<li>Render each namespace node iff:
<ul>
<li>it is <a class="link-def" href="#def-visibly-utilizes">visibly
utilized</a> by the immediate parent element or one of its
attributes, <strong>or</strong> is present in <a class="link-def"
href="#def-InclusiveNamespaces-PrefixList">InclusiveNamespaces
PrefixList</a>, and</li>
<li>its prefix and value <strong>do not</strong> appear in
<code>ns_rendered</code>. <code>ns_rendered</code> is obtained by
popping the <code>state</code> stack in order to obtain a list of
prefixes and their values which have already been rendered by an <a
href="#def-output-parent" class="link-def">output ancestor</a> of
the namespace node's parent element.</li>
</ul>
</li>
<li>Append the rendered namespace node to the list
<code>ns_rendered</code> of namespace nodes rendered by <a
href="#def-output-parent" class="link-def">output ancestor</a>s.
Push <code>ns_rendered</code> on <code>state</code> stack and
recurse.</li>
<li>After the recursion returns, pop the<code>state</code>
stack.</li>
</ol>
<p>(Note, some XPath implementations do not correctly distinguish
namespace nodes from attribute nodes. In [<a
href="#ref-XPath">XPath</a>] an element's namespace axis is
distinct from attribute nodes and it contains all the namespace
declarations from its ancestors. For non-conformant implementations
additional processing and stacks are required to separate a
namespace node list from the attribute node list and keep a stack
of a list of namespace nodes in effect for one's parent.)</p>
</li>
</ol>
<!-- =============================================================================== -->
<h2><a id="sec-Use" name="sec-Use"></a>4. Use in XML Security</h2>
<p>Exclusive Canonicalization may be used as a
<code>Transform</code> or <code>CanonicalizationMethod</code>
algorithm in XML Digital Signature [<a
href="#ref-XML-DSig">XML-DSig</a>] and XML Encryption [<a
href="#ref-XML-Enc">XML-Enc</a>].</p>
<dl>
<dt>Identifier:</dt>
<dd><a
href="http://www.w3.org/2001/10/xml-exc-c14n#">http://www.w3.org/2001/10/xml-exc-c14n#</a>
<p><a
href="http://www.w3.org/2001/10/xml-exc-c14n#WithComments">http://www.w3.org/2001/10/xml-exc-c14n#WithComments</a></p>
</dd>
</dl>
<p>Just as with [<a href="#ref-XML-C14N">XML-C14N</a>] one may use
the "<a name="WithComments" id="WithComments">#WithComments</a>"
parameter to include the serialization of XML comments. This
algorithm also takes an optional explicit parameter of an empty
<code>InclusiveNamespaces</code> element with a
<code>PrefixList</code> attribute. The value of this attribute,
which may be null, is a whitespace delimited list of namespace
prefixes, and where #default indicates the default namespace, to be
handled as per [<a href="#ref-XML-C14N">XML-C14N</a>]. The list is
in NMTOKENS format (a white space separated list). For example:</p>
<pre class="xml-example">
&lt;ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"&gt;
&lt;ec:InclusiveNamespaces PrefixList="dsig soap #default"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/&gt;
&lt;/ds:Transform&gt;
</pre>
<p>indicates the exclusive canonicalization transform, but that
namespaces with prefix "dsig" or "soap" and default namespaces
should be processed according to [<a
href="#ref-XML-C14N">XML-C14N</a>].</p>
<pre class="xml-dtd">
Schema Definition:
&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd"
[
&lt;!ATTLIST schema
xmlns:ec CDATA #FIXED 'http://www.w3.org/2001/10/xml-exc-c14n#'&gt;
&lt;!ENTITY ec 'http://www.w3.org/2001/10/xml-exc-c14n#'&gt;
&lt;!ENTITY % p ''&gt;
&lt;!ENTITY % s ''&gt;
]&gt;
&lt;schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
targetNamespace="http://www.w3.org/2001/10/xml-exc-c14n#"
version="0.1" elementFormDefault="qualified"&gt;
&lt;element name="InclusiveNamespaces"
type="ec:InclusiveNamespaces"/&gt;
&lt;complexType name="InclusiveNamespaces"&gt;
&lt;attribute name="PrefixList" type="NMTOKENS"/&gt;
&lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
DTD:
&lt;!ELEMENT InclusiveNamespaces EMPTY &gt;
&lt;!ATTLIST InclusiveNamespaces
PrefixList NMTOKENS #REQUIRED &gt;
</pre>
<h2>5. <a id="sec-Considerations"
name="sec-Considerations">Security Considerations</a></h2>
<p>This specification is used to serialize an XPath nodeset under
certain assumptions given in [<a href="#ref-XML-C14N">XML-C14N</a>]
and this specification. For example, implementations of [<a
href="#ref-XML-C14N">XML-C14N</a>] do not render a document XML
declaration; when implementations of this specification serialize a
subset they do <em>not</em> render ancestor attributes from the
"xml:" namespace. While we feel such choices are consistent with
other XML specifications and satisfy our application requirements
it is important that an XML application carefully construct its
transforms such that the result is meaningful and unambigous in its
application context. The <a
href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Resolutions">Resolutions</a>
of [<a href="#ref-XML-C14N">XML-C14N</a>] and the <a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-Security">
Security Considerations</a> of [<a
href="#ref-XML-DSig">XML-DSig</a>] should be carefully attended
to.</p>
<h2>6. <a id="sec-References"
name="sec-References">References</a></h2>
<dl>
<dt><a id="ref-Keywords" name="ref-Keywords">Keywords</a></dt>
<dd><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119.</a>
<em>Key words for use in RFCs to Indicate Requirement Levels</em>.
Best Current Practice. S. Bradner. March 1997.S. Bradner. March
1997.</dd>
<dd><a
href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></dd>
<dt><a id="ref-URI" name="ref-URI">URI</a></dt>
<dd><a href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a> .
<i>Uniform Resource Identifiers (URI): Generic Syntax.</i> T.
Berners-Lee, R. Fielding, L. Masinter. August 1998.</dd>
<dd><a
href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a></dd>
<dt><a id="ref-XML" name="ref-XML">XML</a></dt>
<dd><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible
Markup Language (XML) 1.0 (Second Edition).</a> W3C Recommendation.
T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October
2000.</dd>
<dd><a
href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>
.</dd>
<dt><a id="ref-XML-C14N" name="ref-XML-C14N">XML-C14N</a></dt>
<dd><a
href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical
XML.</a> W3C Recommendation. J. Boyer. March 2001.</dd>
<dd><a
href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></dd>
<dd><a
href="http://www.ietf.org/rfc/rfc3076.txt">http://www.ietf.org/rfc/rfc3076.txt</a></dd>
<dt><a id="ref-XML-DSig" name="ref-XML-DSig">XML-DSig</a></dt>
<dd><a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">XML-Signature
Syntax and Processing</a>. IETF Draft/W3C Proposed Recommendation.
D. Eastlake, J. Reagle, and D. Solo. 31 August 2001.</dd>
<dd><a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/</a></dd>
<dt><a name="ref-XML-Fragment"
id="ref-XML-Fragment">XML-Fragment</a></dt>
<dd><a
href="http://www.w3.org/TR/2001/CR-xml-fragment-20010212">XML
Fragment Interchange</a>. W3C Candidate Recommendation. P. Grosso,
D. Veillard. February 2001.</dd>
<dd><a
href="http://www.w3.org/TR/2001/CR-xml-fragment-20010212">http://www.w3.org/TR/2001/CR-xml-fragment-20010212</a></dd>
<dt><a id="ref-XML-NS" name="ref-XML-NS">XML-NS</a></dt>
<dd><a
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces
in XML</a>. W3C Recommendation. T. Bray, D. Hollander, and A.
Layman. January 1999.</dd>
<dd><a
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a></dd>
<dt><a id="ref-XML-Enc" name="ref-XML-Enc">XML-Enc</a></dt>
<dd><a
href="http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018">XML
Encryption Syntax and Processing</a>. D. Eastlake, and J. Reagle.
W3C Working Draft. October 2001.
<p><a
href="http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018">http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018</a></p>
</dd>
<dt><a id="ref-XML-schema"
name="ref-XML-schema">XML-schema</a></dt>
<dd><a
href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML
Schema Part 1: Structures</a> W3C Recommendation. D. Beech, M.
Maloney, N. Mendelsohn, H. Thompson. May 2001.</dd>
<dd><a
href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a><br />
<a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML
Schema Part 2: Datatypes</a> W3C Recommendation. P. Biron, A.
Malhotra. May 2001.
<p>http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</p>
</dd>
<dt><a id="ref-XPath" name="ref-XPath">XPath</a></dt>
<dd><a href="http://www.w3.org/TR/1999/REC-xpath-19991116">XML Path
Language (XPath) Version 1.0</a> , W3C Recommendation. eds. James
Clark and Steven DeRose. 16 November 1999. <a
href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a>.</dd>
</dl>
<!-- =============================================================================== -->
<h2><a id="sec-Acknowledgements" name="sec-Acknowledgements"></a>7.
Acknowledgements (Informative)</h2>
<p>The following people provided valuable feedback that improved
the quality of this specification:</p>
<ul>
<li>Merlin Hughes, Baltimore</li>
<li>Thomas Maslen, DSTC</li>
<li>Paul Denning, MITRE</li>
</ul>
</body>
</html>