RE: Action-539: review C14N2.0

It is very difficult to determine when whitespace is significant. Even whitespace outside of leaf nodes may be significant.

For example in this XHTML snippet
<p><span>Some</span>  <span>Text</span></p>

The space between the close of the first span and the open of the second span is significant. Because if it present it s rendered as "Some Text" whereas if it is absent it become "SomeText" (no spaces)

Norm Walsh had given this example in one the F2Fs.


Because of these kinds of examples, we cannot really do anything intelligent with white space. The trimTextNodes options that we currently have is obviously not foolproof, but it is simple to explain and simple to implement. (Many programming languages have a trim function).  I can't think of anything we can do to make the trimTextNodes better.


Pratik


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, April 20, 2010 10:05 AM
To: Karel Wouters
Cc: XMLSec WG Public List
Subject: RE: Action-539: review C14N2.0

> The signer might not be the one who has produced the document, so he
> might not be in a position to decide what's meaningless.

Yes, that's true, so he probably wouldn't be using that option.
 
> But at the same time, those users might add xml:space=preserve when
> enveloping the signature in another document, precisely to protect all
> their pretty-printing.

Schemas/grammars/specs would have to explicitly permit xml:space to appear
on the root element for that to be a concern. And would those users really
think to do this? Doesn't seem likely to me.

> They don't know that pretty printing will kill
> the signature, so surely they don't know that xml:space=preserve will do
> the same.

Yes, but pretty printing is pretty common, and xml:space is not so much, is
it?

> Conclusion: trimTextNode=true is to be included when signers expect that
> pretty printing will mess up the signature, but can be problematic for
> those pretty printers that also include xml:space=preserve
> 
> So it doesn't protect against all mess-ups, but at least against a
> (considerable?) part of it.

In the cases I'm aware of, "considerable" borders on "virtually all".

-- Scott

Received on Tuesday, 20 April 2010 20:58:21 UTC