Exclusive XML Canonicalization Version 1.0 and (Re: xmlsig-charter)

Dear all,

following up on an email exchange with Thomas Roessler about the topic 
whether "Exclusive XML Canonicalization Version 1.0" 
(http://www.w3.org/TR/xml-exc-c14n/) could suffer similar problems as  
"Canonical XML Version 1.0" when it comes to xml:base information being 
lost - I'd like to bring the following to your attention as this is 
currently on our charter.


Konrad

PS: I'm happy to either discuss this here or to defer the discussion 
until the maintenance work on the XML Security specifications has started.

____________________________________

The question Thomas asked was whether exclusive canonical "Exclusive XML 
Canonicalization Version 1.0" would have the same results no matter 
whether it was based on c14n 1.0 or c14n 1.1 ?

Exclusive c14n 1.0 says: "attributes in the XML namespace, such as 
|xml:lang| and |xml:space| are not imported into orphan nodes of the 
document subset"

And as this rule seems to supersede the xml:base fixup performed in c14n 
1.1 this appears to be true.

Fact is that there are orthogonal interests when exclusively 
canonicalizing inheritable attributes (i.e. from the xml:namespace):

A) "Context free extraction" for Enveloping and de-Enveloping: Here 
context should be lost and an xml transport layer shall not influence 
transformation and canonicalization of the payload.
     E.g.: an xml signature is to be verified in different transport 
layers and shall remain verifiable in other transport layers.

B) "Clean Inheritance necessary to not break URIReferences, XPath 
expressions, and the like" (for URIReferences xml:base context needs to 
be kept)
    E.g. a signature only signs certain parts of a document through an 
XPathFilter(2.0) Transformation. Now the interpretation of  different 
"href"s and other URIReferences might be changeable.

E.g.: Please consider the following document, where <someEnvelope> 
depicts an xml transport protocol

<someEnvelope xml:base="http://www.example.org/env1/file.ext" xml:lang="en">
 <myData xml:base="">
 <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>
 <x/>
 </myData>
</someEnvelope>


Now assume the NodeSet <mydata>, <c>, <d> and <e> is to be canonicalized 
before it can be digested for a signature computation.

Exclusive XML Canonicalization Version 1.0 yields the following and the 
href values will have lost significant context.

 <myData xml:base="">
     <c xml:base="" >
       <d xml:base="" href="file.ext#some-id1">
       </d>
       <e xml:base="#some-fragment" href="file.ext#some-id2">
       </e>
     </c>
 </myData>

The apex Node cannot be explicitly given an xml:base value as it might 
already have one (cf.1.3 Limitations) (here a noop, but it might also be 
a useful one for <x>).

Canonical XML Version 1.1 would yield something like the following so 
that the hrefs of <d> and <e> don't break.
Thi would however only be verifiable in an envelope bequeathing 
xml:base="http://www.example.org/env1/file.ext" and  xml:lang="en" to 
it's child nodes:

 <myData xml:base="http://www.example.org/env1/file.ext" xml:lang="en">
     <c xml:base="http://www.example.org/pathseg1/file.ext" xml:lang="de">
       <d xml:base="" href="file.ext#some-id1">
       </d>
       <e xml:base="#some-fragment" href="file.ext#some-id2">
       </e>
     </c>
</myData>

Ideal from my point of view would be the following output, not breaking 
the hrefs and properly extracting <myData> from it's transport protocol:

  <myData>
     <c xml:base="http://www.example.org/pathseg1/file.ext" xml:lang="de">
       <d xml:base="" href="file.ext#some-id1">
       </d>
       <e xml:base="#some-fragment" href="file.ext#some-id2">
       </e>
     </c>
   </b>
 </myData>

I think a parameter would be required - just like the 
InclusiveNamespaceprefixList - to realize this.
The parameter could take an expression evaluated along the 
parent-or-self axis of the first element node to be rendered by the 
exclusive canonicalization identifying where to loose the context.
e.g.: parent-or-self::*/myData/

____________________________________

In fact in very subtle cases of transforms in xml digital signatures 
XPathFilter Transforms and other transforms receiving a NodeSet as input 
can suffer side effects caused by different transport protocols as these 
can be accessed via the underlying document and cause different output.
If you are interested please cf.
  - 
http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200610/msg00000.html
  - 
http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200608/msg00007.html

In DOM operations like adoptNode help. However this requires a 
commitment to DOM, and I don't know about an equivalent in the XPath 1.0 
Data model on which the specs are based.

-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm