W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

Re: Gregor's EXC-C14N interop samples (WAS:RE: Moving exc-c14n forward: your response is needed!)

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 18 Apr 2002 08:49:52 -0400
Message-Id: <200204181249.IAA01302@tux.w3.org>
To: "Gregor Karlinger" <gregor.karlinger@iaik.at>, <merlin@baltimore.ie>
Cc: "'TAMURA Kent'" <kent@trl.ibm.co.jp>, "'Ari Kermaier'" <arik@phaos.com>, "'Aleksey Sanin'" <aleksey@aleksey.com>, <w3c-ietf-xmldsig@w3.org>
On Thursday 18 April 2002 07:03, Gregor Karlinger wrote:
> > 3. I've tried Gregor's examples and, with one exception
> > (example 4, regular c14n, GrandChild, xml:fool should not be
> > there?), I think everything works.

Yesterday, I was able to confirm all of my examples with Gregor's except 
for normal c14n in example 1.

> I guess that you mean example 1 since this is the only one
> bearing an xml:fool attribute.

Yes, this is the problem I had, and I think Gregor is (unfortunately 
<grin/>) right:

http://mail.python.org/pipermail/xml-sig/2002-April/007646.html

However, I also discovered a bug from Gregor's example 1 [a]. Presently, 
c14n.py does the following:
1. takes any xml_attrs (e.g., xml:lang) from previous recursions not 
rendered and adds them to local xml_attrs.
2. if the element we are processing is in the subset, it renders the 
accumulated xml_attrs as part of that element and and resets xml_attrs=[] 
3. it recurses.

This has the effect of rendering all XML attributes that are "in affect" 
since the last ancestor was rendered. Sounds sensible, but it's not correct 
according to the the spec [b]. To fix this, I think we'd have to test 
whether the immediate parent was in the nodeset and keep a dictionary 
(instead of a list) of *all* ancestors' xml:foo attributes (not just since 
the nearest rendered one), with the *nearest* value. (Moving from a list to 
a dictionary is akin to what I did for the namespace bug.) This bug exists 
on in c14n, not exc-c14n. 
Received on Thursday, 18 April 2002 08:51:05 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:15 GMT