W3C home > Mailing lists > Public > public-xmlsec@w3.org > June 2010

Re: C14N2.0: ugly little details

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 29 Jun 2010 15:46:13 +0200
To: <Meiko.Jensen@ruhr-uni-bochum.de>
CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Message-ID: <4B9C88FB-EBFA-4EEC-B07E-B688C2402EE8@nokia.com>
> So, the problem is to determine whether two
> adjacent text nodes result from a parser splitting a single text node or
> from two separate XPath selections.

Is this an example of the parser "going first" before C14N2, therefore C14N2 not being able to enforce whitespace trimming?

regards, Frederick

Frederick Hirsch
Nokia




On Jun 29, 2010, at 7:55 AM, ext Meiko Jensen wrote:

> Hi all,
> 
> discussing the C14N2.0 with a student we found a very interesting little
> detail of the actual C14N2.0 approach, which I'd like to point your
> attention to.
> 
> Consider the Document
> 
> <X>
>  <A>1 </A>
>  <B> 2</B>
> </X>
> 
> Note the whitespace behind 1 and before 2. DSIG2-Selection includes the
> XPaths /X/A/text() and /X/B/text(), hence the C14N2.0 gets an input made
> up by two text nodes: "1 " and " 2".
> First, this is no XML any more. No problem so far. However, it is shaped
> by two adjacent text nodes, so in the trimTextNodes=true case this
> should result in a removal of leading and trailing whitespaces. For
> performing C14N on each single text node, this would mean a C14N output
> of "12", but since a parser would consider both text nodes to be
> adjacent, hence "concatenatable", a more realistic output would be "1 
> 2", keeping the two spaces. So, the problem is to determine whether two
> adjacent text nodes result from a parser splitting a single text node or
> from two separate XPath selections.
> 
> After all, it means that concatenation of two C14Ned XML fragments is no
> longer equivalent to C14N performed on their concatenation. Not sure
> whether this may turn out to be a problem one day.
> 
> We could leave this open and go along with the "1  2" result as being
> correct (which is most easy and inline with what we specified in "first
> Selection, then C14N") or put a word or two on this in the spec or in
> best practices.
> 
> What do you think?
> 
> Meiko
> 
> -- 
> Dipl.-Inf. Meiko Jensen
> Chair for Network and Data Security 
> Horst Görtz Institute for IT-Security 
> Ruhr University Bochum, Germany
> _____________________________
> Universitätsstr. 150, Geb. IC 4/150
> D-44780 Bochum, Germany
> Phone: +49 (0) 234 / 32-26796
> Telefax: +49 (0) 234 / 32-14347
> http:// www.nds.rub.de
> 
> 
Received on Tuesday, 29 June 2010 13:47:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 June 2010 13:47:14 GMT