Re: Interop and c14n(x) != c14n(c14n(x))

--On Freitag, 24. Mai 2002 18:47 +0100 merlin <merlin@baltimore.ie> wrote:

>
> Hi Christian,
>
> There are at least two problems I see with your c14n:
>   ...
>   <ds:Reference URI="#object1">
>   <ds:Transforms>
>   <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
>   <ds:XPath>self::node()[local-name()='included']</ds:XPath>
>   </ds:Transform>
>   </ds:Transforms>
>   ...
>   <ds:Object Id="object1">
>   <included xml:lang="de">
>   <notIncluded>
>   <notIncluded xml:lang="uk">
>   <included>
>   </included>
>   </notIncluded>
>   </notIncluded>
>   </included>
>   </ds:Object>
>   ...
>
> Your c14n is:
>
> <included xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> xml:lang="de"><included xml:lang="uk"></included></included>
>
> 1) Your XPath does not include any nodes from the namespace
> axis, so xmlns:ds="http://www.w3.org/2000/09/xmldsig#" should
> not be emitted. You probably want an XPath of this form (I
> haven't thought much about it):
>   count(ancestor-or-self::included) >
>     count(ancestor-or-self::notIncluded[1]/ancestor::included)
> This will include xml:lang="de" which you may or may not want;
> tweak as necessary.
>
> If you want a detailed discussion of the disconnect between
> the XPath info set concept of the namespace axis and DOM,
> look back at some of the threads from one or two years ago.
> I know I contributed my confusion to some of them.

The only thing I've seen was something like this:

<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000OctDec/0036.html>

Would it be possible that you create some obfuscated nodesets in a 
signature to have a good test vector? I mean canonicalizing a node set 
which omits xmlns:*, xmlns and xml:* attributes in both element which are 
part of the node set and elements which are not included in the node set.

That would be VERY nice. In all other test vectors I use for unit testing 
and interop, I don't have such esoteric node sets.



> 2) xml:lang="de" is not defined in the ancestor axis of the
> first included element, and is not included in the node set,
> so should not be emitted.
>
> While I'm not convinced that there is a requirement that
> c14n(X) == c14n(c14n(X)) - c14n produces the canonical form of
> a node set, and the output of c14n is not the same node set
> as the input, so there is not a claim that the outputs should
> necessarily be the same - I think in fact that property may
> hold true.
>
> Can you send a clearer counterexample in-line, even just
> in pseudo XML?

It's not that important, just an idea. If you take this fragment and you 
take all nodes but the notIncluded element into the node set:

<included xml:foo="bar" xml:lang="de">
<notIncluded>
<included>
</included>
</notIncluded>
</included>

Then Canonical XML produces the following octet stream:

<included xml:foo="bar" xml:lang="de">

<included xml:foo="bar" xml:lang="de">
</included>

</included>

If you canonicalize this octet stream again, you get

<included xml:foo="bar" xml:lang="de">

<included>
</included>

</included>

That was what I wanted to express with "c14n(node set X) != c14n(c14n(node 
set X))"

But I see that this is not only the case for the xml:* attributes but also 
leading and trailing whitespace which is outside the "new" document element 
after c14n.

Received on Friday, 24 May 2002 15:42:08 UTC