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.
724 lines
29 KiB
724 lines
29 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Known Issues with Canonical XML 1.0 (C14N/1.0)</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li, p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
|
|
div.assertion { border: 4px double gray; padding: 0.5em; margin-bottom: 0.2em; }
|
|
blockquote { background-color: #eeeeee; }
|
|
spectext { background-color: #eeeeee; }
|
|
.message { background-color: #d5dee3; }
|
|
|
|
|
|
pre { margin-left: 4em}
|
|
|
|
p.diff-chg,
|
|
li.diff-chg,
|
|
h1.diff-chg,
|
|
h2.diff-chg,
|
|
h3.diff-chg,
|
|
h4.diff-chg,
|
|
h5.diff-chg,
|
|
h6.diff-chg,
|
|
td.diff-chg,
|
|
tr.diff-chg { background-color: #E47833; }
|
|
p.diff-del,
|
|
li.diff-del,
|
|
h1.diff-del,
|
|
h2.diff-del,
|
|
h3.diff-del,
|
|
h4.diff-del,
|
|
h5.diff-del,
|
|
h6.diff-del,
|
|
td.diff-del,
|
|
tr.diff-del { background-color: red; text-decoration: line-through;}
|
|
p.diff-add,
|
|
p.diff-add,
|
|
h1.diff-add,
|
|
h2.diff-add,
|
|
h3.diff-add,
|
|
h4.diff-add,
|
|
h5.diff-add,
|
|
h6.diff-add,
|
|
td.diff-add,
|
|
tr.diff-add { background-color: lime; }
|
|
table { empty-cells: show; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
div.table,
|
|
div.figure {margin-top: 2em;
|
|
margin-bottom: 2em;
|
|
text-align: center; }
|
|
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"></head><body>
|
|
|
|
<div class="head"><p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
|
|
<h1>Known Issues with Canonical XML 1.0 (C14N/1.0)</h1>
|
|
<h2>W3C Working Group Note 20 December 2006</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/">http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/C14N-issues/">http://www.w3.org/TR/C14N-issues/</a></dd><dt>Previous versions:</dt><dd><a href="http://www.w3.org/TR/2006/WD-C14N-issues-20060915/">http://www.w3.org/TR/2006/WD-C14N-issues-20060915/</a></dd><dt>Editors:</dt>
|
|
<dd>José Kahan, <a href="http://www.w3.org/">W3C</a></dd>
|
|
<dd>Konrad Lanz, <a href="http://www.a-sit.at/">A-SIT</a></dd>
|
|
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2006 <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><div>
|
|
<h2><a name="abstract">Abstract</a></h2>
|
|
|
|
|
|
|
|
<p>This technical note addresses some of the issues related to
|
|
inheritance of the XML attributes <code>xml:base</code> and <code>xml:id</code> and the W3C
|
|
Recommendation for Canonical XML Version 1.0 [<a href="#C14N10">C14N10</a>] (<a href="http://www.w3.org/2001/03/C14N-errata">Errata</a>). Shortcomings of C14N/1.0
|
|
are noted out and the use of a new C14N/1.1 recommendation
|
|
with the XML Digital Signature 1.0 Recommendation [<a href="#XMLDSIG">XMLDSIG</a>] is discussed.
|
|
|
|
|
|
</p>
|
|
|
|
</div><div>
|
|
<h2><a name="status">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/" shape="rect">W3C technical
|
|
reports index</a> at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This is the <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#q75">W3C
|
|
Working Group Note</a> of "Known Issues with Canonical XML 1.0
|
|
(C14N/1.0)", produced by the <a href="http://www.w3.org/XML/Core/" shape="rect">XML Core Working Group</a>, as part of the <a href="http://www.w3.org/XML/Activity">XML Activity</a>. A
|
|
companion note, "XML Digital Signatures in the 2006 XML Environment"
|
|
[<a href="#XMLDSIG2006" shape="rect">XMLDSIG2006</a>], describes in
|
|
further detail how a revised canonicalization algorithm (C14N/1.1 or
|
|
other) may be used with the current XML-SIG/1.0 Specification.</p>
|
|
|
|
|
|
|
|
<p>Please send comments related to this document to <a href="mailto:www-xml-canonicalization-comments@w3.org" shape="rect">www-xml-canonicalization-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/" shape="rect">public archive</a>).</p>
|
|
|
|
<p>Publication as a Working Group Note does not imply endorsement by
|
|
the W3C Membership. This is a draft document and may be updated,
|
|
replaced or obsoleted by other documents at any time. It is
|
|
inappropriate to cite this document as other than work in
|
|
progress.</p>
|
|
|
|
<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2002/08/xmlcore-IPR-statements">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must 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>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<hr><div class="toc">
|
|
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#S1">Overview</a><br>2. <a href="#S2">Interaction with XML Base</a><br>3. <a href="#S3">Interaction with XML Id</a><br>4. <a href="#S4">Implicit use of Canonical XML 1.0 by XML Signature</a><br>5. <a href="#S5">Further considerations for C14N/1.1</a><br>6. <a href="#Ref">References</a><br>7. <a href="#Ack">Acknowledgments</a><br></p></div><hr><div class="toc">
|
|
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#S1">Overview</a><br>2. <a href="#S2">Interaction with XML Base</a><br> 2.1 <a href="#S21">Inheriting xml:base values</a><br> 2.2 <a href="#S22">Special values of xml:base</a><br>3. <a href="#S3">Interaction with XML Id</a><br>4. <a href="#S4">Implicit use of Canonical XML 1.0 by XML Signature</a><br>5. <a href="#S5">Further considerations for C14N/1.1</a><br> 5.1 <a href="#S5_1">xml:base and URI reference simplification</a><br> 5.2 <a href="#S5_2">An XML infoset strategy for canonicalizing XML base</a><br>6. <a href="#Ref">References</a><br>7. <a href="#Ack">Acknowledgments</a><br></p>
|
|
<h3><a name="appendix" id="appendix">Appendix</a></h3><p class="toc"></p></div><hr><div class="body">
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="S1"></a>1. Overview</h2>
|
|
<p>Section 2.4 of the Canonical XML 1.0 [<a href="http://www.w3.org/TR/xml-c14n#DocSubsets">C14N10</a>]
|
|
Specification defines special treatment for attributes in the
|
|
<code>XML</code> namespace when a representation of a document subset
|
|
is generated. The processing specified assumes that attributes in the
|
|
XML namespace are inherited by copying them from the nearest ancestor.
|
|
The inheritance rule given is appropriate for the processing of the <code>xml:space</code> and
|
|
<code>xml:lang</code> attributes, but not for <code>xml:base</code>, which
|
|
needs a special inheritance mechanism, or for <code>xml:id</code>, which
|
|
should not be inherited at all. [<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0004.html">XML-BASE-Problem</a>].</p>
|
|
|
|
|
|
<p>Related problems exist in the Decryption Transform for XML
|
|
Signature [<a href="#XMLENCDEC">XMLENCDEC</a>] W3C
|
|
Recommendation, which applies a modified C14N/1.0 algorithm and
|
|
adds additional rules concerning the copying of attributes in
|
|
the <code>xml</code> namespace. These rules are based on the
|
|
same assumptions as their counterparts in C14N/1.0.</p>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="S2"></a>2. Interaction with XML Base</h2>
|
|
|
|
<p>The XML Base Recommendation [<a href="#XMLBASE">XMLBASE</a>] defines
|
|
the base URI of an element as the value of the element's
|
|
<code>xml:base</code> attribute, the base URI of the element's
|
|
parent element within the document or external entity, or the base
|
|
URI of the document entity or external entity containing the
|
|
element. In particular, the meaning of relative URI references in
|
|
an <code>xml:base</code> attribute can depend on the chain of
|
|
<code>xml:base</code> attributes along an element's ancestor axis.</p>
|
|
|
|
<p>The canonicalization of <code>xml:base</code> requires a more
|
|
specific algorithm than just copying or inheriting the values of
|
|
preceding <code>xml:base</code> attributes. The following cases must
|
|
be taken into account:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><code>xml:base</code> values may consist of
|
|
only a fragment identifier (this is a no-op)</p>
|
|
</li>
|
|
<li>
|
|
<p><code>xml:base</code> values may be empty
|
|
(this is a no-op)</p>
|
|
</li>
|
|
<li>
|
|
<p><code>xml:base</code> values may be absolute or relative URI references</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="S21"></a>2.1 Inheriting xml:base values</h3>
|
|
|
|
<p>Depending on the input node set to canonical xml, one can either
|
|
canonicalize a whole document or a subset of the document's nodes.
|
|
For example, in [<a href="#XMLDSIG">XMLDSIG</a>], one can use either
|
|
XPointer to dereference only parts of a document or XPath Filter and
|
|
XPath Filter 2.0 transforms to refer to a given fragment of the
|
|
document that one wants to sign.</p>
|
|
|
|
<p>Consider the following XML document (document 1):</p>
|
|
|
|
<div class="figure" id="document1">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<a xml:lang="en">
|
|
<b xml:base="http://www.example.org/pathseg1/" xml:lang="de">
|
|
<c>
|
|
</c>
|
|
</b>
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 1: Sample XML document 1</p>
|
|
</div>
|
|
|
|
<p>We now canonicalize document 1 with the input nodeset of c14n being
|
|
the element <code><c></code>. The element nodes along
|
|
<code><c></code>'s ancestor axis are examined for the first
|
|
occurence of any <code>xml</code> namespace axis, and these are then
|
|
merged into the attribute list of <code><c></code>.</p>
|
|
|
|
<div class="figure" id="document1-canonicalized">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<c xml:base="http://www.example.org/pathseg1/" xml:lang="de">
|
|
</c>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 2: Canonical form of sample XML document 1</p>
|
|
</div>
|
|
|
|
<p>The <code>xml:base</code> attribute on the <code><c/></code>
|
|
element in the canonicalized node-set indeed contains the base URI of
|
|
the <code><c/></code> element as present in document 1.</p>
|
|
|
|
<p>Up to now, there have been no problems with the simple duplication
|
|
of <code>xml:base</code> for maintaining the inheritance. However,
|
|
this is not always possible. Let's now consider the following XML
|
|
document (document 2):</p>
|
|
|
|
<div class="figure" id="document2">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<a xml:base="http://www.example.org/pathseg1/" xml:lang="en">
|
|
<b xml:base="../pathsegA/" xml:lang="de" >
|
|
<c>
|
|
</c>
|
|
</b>
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 3: Sample XML document 2</p>
|
|
</div>
|
|
|
|
|
|
<p>We now canonicalize document 2, the input nodeset of c14n being the element <c></p>
|
|
|
|
<div class="figure" id="document2-canonicalized">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<c xml:base="../pathsegA/" xml:lang="de">
|
|
</c>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 4: Canonical form of sample XML document 2</p>
|
|
</div>
|
|
|
|
<p>
|
|
In the case of <code>xml:lang</code>, copying the parent's
|
|
attributes allowed to retain the context. In the case of
|
|
<code>xml:base</code>, we have lost the context of how to resolve the
|
|
relative URI reference. Thus, for a given node-set, the application of the C14N/1.0
|
|
inheritance rule can lead to <code>xml:base</code>
|
|
attributes which specify a base URI that is different from the one
|
|
in the original document context.
|
|
</p>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="S22"></a>2.2 Special values of xml:base</h3>
|
|
|
|
<p>C14N/1.0 also has issues in that it doesn't know how to process
|
|
<code>xml:base</code> attributes that have no value or have values
|
|
that are a same-document (section 4.2 [<a href="#RFC2396">RFC
|
|
2396</a>]) reference. As indicated by <a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Jun/0021">
|
|
Roy Fielding and Richard Tobin</a> these should be treated as do
|
|
nothing or no operation (noop) in <code>xml:base</code>.</p>
|
|
|
|
<p>Consider the following document located at (<code>file:///tmp/doc.xml</code>):</p>
|
|
|
|
<div class="figure" id="document3">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<a xml:base="http://www.example.org/pathseg1/">
|
|
<b xml:base="file.ext" xml:lang="de">
|
|
<c xml:base="" >
|
|
<d xml:base="" href="file.ext#some-id1">
|
|
</d>
|
|
<e xml:base="#some-fragment" href="file.ext#some-id2">
|
|
</e>
|
|
</c>
|
|
</b>
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 5: Sample XML document 3</p>
|
|
</div>
|
|
|
|
<p>We now canonicalize document 3 with the input nodeset of C14N/1.0 being
|
|
the element <code><c></code> and all its descendants:</p>
|
|
|
|
<div class="figure" id="document3-canonicalized">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<c xml:base="">
|
|
<d xml:base="" href="#some-id1">
|
|
</d>
|
|
<e xml:base="#some-fragment" href="#some-id2">
|
|
</e>
|
|
</c>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 6: Incorrect canonical form of sample XML document 3</p>
|
|
</div>
|
|
|
|
<p>As there already exists an <code>xml:base=""</code> attribute in
|
|
<code><c></code>, C14N/1.0 rules won't let <code>
|
|
<c></code> inherit
|
|
<code>xml:base="http://www.example.org/pathseg1/file.ext"</code>.</p>
|
|
|
|
<p>Let's now consider the case that the node that has
|
|
<code>xml:base=""</code> is in the input-nodeset and that
|
|
<code>xml:base=""</code> is considered as a no operation (noop).
|
|
According to the C14N/1.0 rules, we would need to copy the ancestor's
|
|
value that is not in the input-nodeset. However, this would not
|
|
suffice.</p>
|
|
|
|
<p>The inheritance rules of the XML Base Recommendation [<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/#resolution">XMLBASE,
|
|
section 4</a>] allows for succesive use of relative references. Also,
|
|
such sucessive relative references may not be in the input node set
|
|
and hence not rendered. So an inheritance rule for
|
|
<code>xml:base</code> would have to combine <code>xml:base=""</code>
|
|
with its omitted ancestors <code>xml:base</code> values. However this
|
|
is not stated.</p>
|
|
|
|
<p>A correct canonicalization of element <c> and all its
|
|
descendants that preserves the base URI from the original context
|
|
would be as follows:</p>
|
|
|
|
<div class="figure" id="document3-canonicalized-correctly">
|
|
<blockquote>
|
|
<pre style="text-align: left">
|
|
<?xml version="1.0"?>
|
|
<c xml:base="http://www.example.org/pathseg1/file.ext" >
|
|
<d href="file.ext#some-id1">
|
|
</d>
|
|
<e href="file.ext#some-id2">
|
|
</e>
|
|
</c>
|
|
</pre>
|
|
</blockquote>
|
|
<p>Figure 7: Correct canonical form of sample XML document 3</p>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="S3"></a>3. Interaction with XML Id</h2>
|
|
|
|
<p>The <code>xml:id</code> [<a href="#XMLID">XMLID</a>] attribute is part of the
|
|
XML information Set [<a href="#XMLINFOSET">XMLINFOSET</a>]. It allows
|
|
to associate any XML element with a unique identifier. Therefore, the
|
|
value of a given <code>xml:id</code> attribute is unique within an XML
|
|
document. The <code>xml:id</code> Recommendation was issued after
|
|
Canonical XML 1.0 had become a Recommendation.</p>
|
|
|
|
<p>The recommended C14N/1.0 processing behavior that requires
|
|
inheritance of attributes by copying them from the nearest ancestor
|
|
can produce badly-formed documents with respect to the <code>xml:id</code>
|
|
recommendation. Consider the following fragment of an XML
|
|
document:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<a xml:id="id_a">
|
|
<b />
|
|
<c />
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>If we select the children of node <code><a></code> and apply the C14N/1.0
|
|
processing rules, both node <code><b></code> and
|
|
<code><c></code> would obtain a copy of <code><a></code>'s
|
|
<code>xml:id</code> attribute. This produces a badly-formed XML
|
|
document as two <code>xml:id</code> attributes have the same
|
|
value:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<b xml:id="id_a" />
|
|
<c xml:id="id_a" />
|
|
</pre>
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<p>Note that even if only element inherited the <code>xml:id</code>
|
|
attribute, the result would still be wrong - the <code>xml:id</code>
|
|
attribute value would be assigned to the wrong element. For example,
|
|
let's now select node <code><b></code>. The C14N/1.0 processing would
|
|
assign node <code><a></code>'s <code>xml:id</code> attribute value
|
|
to node <code><b></code>:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<b xml:id="id_a" />
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>Therefore, C14N/1.0 cannot be applied to documents containing
|
|
<code>xml:id</code> attributes. Inheritance of any <code>xml:id</code>
|
|
attributes would produce a wrong or a badly-formed document.</p>
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="S4"></a>4. Implicit use of Canonical XML 1.0 by XML Signature</h2>
|
|
|
|
<p>XML Signature [<a href="#XMLDSIG">XMLDSIG</a>] identifies the
|
|
canonicalization method by an URI inside
|
|
<code><ds:CanonicalizationMethod></code> on a
|
|
<code><ds:SignedInfo></code> level. More importantly, the same
|
|
is needed on the data object or <code><ds:Manifest></code> level
|
|
by using a <code><ds:Transform></code> inside a
|
|
<code><ds:Reference></code>. In the latter case, if no such
|
|
<code><ds:Transform></code> is given on the data object level,
|
|
and if a node-set is subject to a transformation that requires an
|
|
octet stream or is to be hashed using the message digest, the <a href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">XML
|
|
Signature Reference Processing Model</a> uses Canonical XML C14N/1.0
|
|
implicitly to convert a node-set into an octet stream.</p>
|
|
|
|
<p>
|
|
If applications require processing according to a particular version
|
|
of Canonical XML, then they should explicitly give the appropriate
|
|
algorithm URI. Specifically, the following cases must be taken into
|
|
account:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>insert an explicit
|
|
<code><ds:Transform></code>
|
|
invoking a new version of Canonical XML before each
|
|
<code><ds:Transform></code> that
|
|
requires an octet stream as input, but is
|
|
applied to a node-set</p>
|
|
</li>
|
|
<li>
|
|
<p>if the previous transform
|
|
outputs a note-set, append a <code><ds:Transform></code>
|
|
invoking a new version of Canonical XML as the last
|
|
<code><ds:Transform></code> before the
|
|
digest input.</p>
|
|
</li>
|
|
<li>
|
|
<p>use this URI inside <code><ds:CanonicalizationMethod></code></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Such an approach, however, will increase the size and the complexity of
|
|
XML digital signatures. Future versions of XML Signature [<a href="#XMLDSIG">XMLDSIG</a>] should consider the use of
|
|
<code><ds:CanonicalizationMethod></code> to specify a default
|
|
node-set to octet stream conversion method for the <a href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">XML
|
|
Signature Reference Processing Model</a>.</p>
|
|
|
|
<p>One should also note that a lot of care will have to be taken on
|
|
future signature creation as all transforms (including the digest)
|
|
that require an octet stream as input but are applied to a node-set
|
|
will need to have such a revised version of Canonical XML as
|
|
<code><ds:Transform></code> before it is input.</p>
|
|
|
|
<p>For further information, please refer to the companion note, "XML
|
|
Digital Signatures in the 2006 XML Environment [<a href="#XMLDSIG2006">XMLDSIG2006</a>], which describes with more
|
|
detail how a revised canonicalization algorithm (C14N/1.1 or other)
|
|
may be used with the current XML-SIG/1.0 Specification.</p>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="S5"></a>5. Further considerations for C14N/1.1</h2>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="S5_1"></a>5.1 xml:base and URI reference simplification</h3>
|
|
|
|
<p>Inheritance rules will also have to be able to deal with relative
|
|
references having "./" and "../" segments apearing in the values for
|
|
<code>xml:base</code>.
|
|
</p>
|
|
|
|
<p>According to the rules laid down in the XML Base Recommendation [<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/#resolution">XMLBASE,
|
|
Section 4</a>], relative references are resolved against the
|
|
<code>xml:base</code> attribute of the element or element's
|
|
ancestor. This implies that relative references are absolutized and
|
|
normalized as specified in [<a href="#RFC2396">RFC 2396, Section
|
|
5.2</a>].</p>
|
|
|
|
<p>This operation can only be performed from the outermost to the
|
|
innermost relative reference. Thus, there is no value in keeping dot
|
|
and dot-dot-segments when fixing up relative reference values of
|
|
<code>xml:base</code> when defining an inheritance rule for
|
|
canonicalizing <code>xml:base</code> attributes.</p>
|
|
|
|
<p>Some special considerations are needed. When normalizing a relative
|
|
URI reference, it is crucial to keep the leading "../" segments of
|
|
relative-path references. Otherwise, path-segments of ancestors'
|
|
<code>xml:base</code> URIs may not be removed appropriately. Another
|
|
issue is that one could create erroneous output that looks similar to
|
|
that of a network-path reference when normalizing an absolute-path reference.
|
|
For instance, an incorrect
|
|
normalization of
|
|
<code>"seg/.././/pseudo-networkpath/seg/file.ext"</code>
|
|
would be <code>//pseudo-netpath/seg/file.ext</code>.</p>
|
|
<p>Note: [<a href="#RFC3986">RFC 3986, Section 4.2</a>] defines the terms
|
|
relative-path, network-path and absolute-path reference as used in
|
|
this document.
|
|
</p>
|
|
|
|
<p>The removal of dot-segments cause more logically equivalent
|
|
documents to produce the same canonicalized output. Furthermore, XML
|
|
Signatures [<a href="#XMLDSIG">XMLDSIG</a>] will benefit from such
|
|
normalization as the likelyhood of false negatives on signature
|
|
validation decreases.
|
|
</p>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="S5_2"></a>5.2 An XML infoset strategy for canonicalizing XML base</h3>
|
|
|
|
<p>
|
|
As stated earlier in this note, the rules for the inheritance of
|
|
<code>xml:base</code> require many considerations. Another more
|
|
straight-forward approach would be to use a strategy based on the XML
|
|
infoset [<a href="#C14N-INFOSET">C14N-INFOSET</a>], namely:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>Use the name <code>EII</code> for an element information item to be
|
|
canonicalized, and <code>EIIC</code> for the element information item
|
|
corresponding to <code>EII</code> in the result of parsing the canonical
|
|
serialization of the node-set containing <code>EII</code>.</li>
|
|
|
|
<li>Synthesize an xml:base attribute for <code>EII</code> iff the
|
|
<code>EIIC</code>'s [base URI] would otherwise be different from
|
|
<code>EII</code>'s [base URI].</li>
|
|
|
|
</ul>
|
|
|
|
<p>This has the advantage that not only does it correctly produce</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<a xml:base="http://example.org">
|
|
<c xml:base="test/" />
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>from</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<a xml:base="http://example.org">
|
|
<b xml:base="test/ ">
|
|
<c/>
|
|
</b>
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
when <code><b>...</b</code>> is filtered out, but it will also correctly produce
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<a xml:base="http://example.org">
|
|
<c xml:base="http://example.org/test/test/" />
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>from</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<a xml:base="http://example.org">
|
|
<b xml:base="test/">
|
|
<c xml:base="test/" />
|
|
</b>
|
|
</a>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
|
|
<p>when <code><b>...</b></code> is filtered out.</p>
|
|
|
|
<p>But we can't say it that way, because C14N as written does not use
|
|
the infoset. Cannonical XML is currently defined on the XPath data
|
|
model.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="Ref"></a>6. References</h2>
|
|
|
|
<dl>
|
|
|
|
<dt class="label"><a name="C14N10"></a>[C14N10] </dt><dd>
|
|
<a href="http://www.w3.org/TR/xml-c14n"><cite>Canonical XML
|
|
Version 1.0</cite></a>, J. Boyer. W3C Recommendation, 15 March 2001,
|
|
<a href="http://www.w3.org/TR/xml-c14n">http://www.w3.org/TR/xml-c14n</a>
|
|
(<a href="http://www.w3.org/2001/03/C14N-errata">Errata</a>).
|
|
</dd>
|
|
|
|
<dt class="label"><a name="C14N-INFOSET"></a>[C14N-INFOSET] </dt><dd>
|
|
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html"><cite>
|
|
An infoset-based strategy for canonicalizing xml:base</cite></a>, H. S. Thompson. XML-CORE Public Mailing list, 6 March 2006,
|
|
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html">http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html</a>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="RFC2396"></a>[RFC2396] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource Identifiers
|
|
(URI): Generic Syntax</cite></a>, T. Berners-Lee MIT/LCS, R. Fielding U.C. Irvine,
|
|
L. Masinter Xerox Corporation, August 1998
|
|
<a href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="RFC3986"></a>[RFC3986] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource Identifiers
|
|
(URI): Generic Syntax</cite></a>, T. Berners-Lee W3C/MIT, R. Fielding Day Software,
|
|
L. Masinter Adobe Systems, January 2005
|
|
<a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLBASE"></a>[XMLBASE] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/"><cite>XML Base
|
|
</cite></a>, J. Marsh. W3C Recommendation, 27 June 2001,
|
|
<a href="http://www.w3.org/TR/xmlbase/">http://www.w3.org/TR/xmlbase/</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLDSIG2006"></a>[XMLDSIG2006] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/"><cite>Using XML Digital Signatures in the 2006 XML Environment</cite></a>, T. Roessler.
|
|
W3C Working Group Note, 20 Dec 2006,
|
|
<a href="http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/">
|
|
http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLENCDEC"></a>[XMLENCDEC] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210"><cite>Decryption Transform for XML Signature</cite></a>, M. Hughes, T. Imamura, H. Maruyama. W3C Recommendation, 10 December 2002,
|
|
<a href="http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210">
|
|
http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLID"></a>[XMLID] </dt><dd>
|
|
<a href="http://www.w3.org/TR/xml-id/"><cite>xml:id Version 1.0
|
|
</cite></a>, J. Marsh, D. Veillard, N. Walsh. W3C Recommendation,9 September 2005,
|
|
<a href="http://www.w3.org/TR/xml-id/">http://www.w3.org/TR/xml-id/</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLINFOSET"></a>[XMLINFOSET] </dt><dd>
|
|
<a href="http://www.w3.org/TR/xml-infoset/"><cite>XML Information Set (Second Edition)
|
|
</cite></a>, J. Cowan and R. Tobin, editors W3C Recommendation, 4 February 2004,
|
|
<a href="http://www.w3.org/TR/xml-infoset/">http://www.w3.org/TR/xml-infoset/</a>.
|
|
</dd>
|
|
|
|
<dt class="label"><a name="XMLDSIG"></a>[XMLDSIG] </dt><dd><a href="http://www.w3.org/TR/xmldsig-core/"><cite>XML-Signature Syntax and
|
|
Processing</cite></a>, D. Eastlake, J. R., D. Solo, M. Bartel,
|
|
J. Boyer , B. Fox , E. Simon. W3C Recommendation, 12 February
|
|
2002, <a href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a>.
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="Ack"></a>7. Acknowledgments</h2>
|
|
|
|
<p>This note is based on based on input from John Boyer, Roy Fielding, Larry Masinter,
|
|
Thomas Roessler, the members of the XML Core Working Group, and the members of the xml-dsig mailing list.
|
|
</p>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="back">
|
|
|
|
</div>
|
|
</body></html>
|