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

Re: Error in merlin-iaikTests-two.tar.gz?

From: merlin <merlin@baltimore.ie>
Date: Thu, 23 May 2002 15:23:42 +0100
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: Gregor Karlinger <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org, jboyer@PureEdge.com
Message-Id: <20020523142342.13FAD4432D@yog-sothoth.ie.baltimore.com>

Hi Christian,

I believe you're right. I think it's just a small oversight in
the spec that we'll have to live with. Exclusive c14n doesn't
seem to have this feature.


>Hi Merlin,
>OK, I understood the writing. But now a question. Given the following 
>document. The document subset is formed of the C and E element (//C | //E).
><a xml:a="xmla">
><C xml:C="xmlC">
><d xml:d="xmld">
>Is the result after c14n this one? I read the c14n spec so:
><C xml:a="xmla" xml:C="xmlC">
><E xml:a="xmla" xml:C="xmlC" xml:d="xmld">
>That's really strange. Intuitively, I'd guessed:
><C xml:a="xmla" xml:C="xmlC">
><E xml:d="xmld">
>--On Donnerstag, 23. Mai 2002 14:24 +0100 merlin <merlin@baltimore.ie> 
>> Hi Christian,
>> This is a feature of the c14n spec; see the second paragraph
>> of 2.4:
>>   The processing of an element node E MUST be modified slightly when an
>>   XPath node-set is given as input and the element's parent is omitted
>>   from the node-set. The method for processing the attribute axis of an
>>   element E in the node-set is enhanced. All element nodes along E's
>>   ancestor axis are examined for nearest occurrences of attributes in the
>>   xml namespace, such as xml:lang and xml:space (whether or not they are
>>   in the node-set). From this list of attributes, remove any that are in
>>   E's attribute axis (whether or not they are in the node-set). Then,
>>   lexicographically merge this attribute list with the nodes of E's
>>   attribute axis that are in the node-set. The result of visiting the
>>   attribute axis is computed by processing the attribute nodes in this
>>   merged attribute list.
>> This probably isn't aesthetically ideal; however, it doesn't
>> cause any problems.
>> Merlin
>> r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.05.23/14:45:23
>>> Hi Merlin,
>>> I have a problem to verify your signature.xml from
>>> merlin-iaikTests-two.tar.gz which was for testing exclusive c14n: The
>>> first  Reference (digest input in c14n-0.xml) seems to be wrong. The
>>> others can be  verified. It looks like this (indentation added by me):
>>> - c14n-0.xml -----------------------
>>> <Parent xml:foo="bar"
>>>        xml:fool="barbar"
>>>        xml:lang="en"
>>>        xml:space="default">
>>> <GrandChild xml:foo="barbarossa"
>>>            xml:fool="barbar"
>>>            xml:lang="ge"
>>>            xml:space="preserve"></GrandChild>
>>> </Parent>
>>> ----------------------------------
>>> This reference was simply the XPath transform (and implicit inclusive
>>> c14n  omitting comments). What I see is that both the Parent and the
>>> GrandChild  have a xml:fool="barbar" attribute while the GrandChild
>>> shouldn't.
>>> Regards,
>>> Christian

The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
Received on Thursday, 23 May 2002 10:23:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC