Re: Action-539: review C14N2.0

On 20/04/2010 17:57, Scott Cantor wrote:
>> 1) when an XML signature is embedded in a XML document that includes
>> xml:space=preserve in the root element, will that break the signature if
>> trimTextNode=true, supposing some trimming was performed?
>> If so, is this desirable behaviour?
> 
> If the intent is to honor xml:space, it has to be inherited as defined by
> the XML spec, I think. So it would apply down below and would prevent
> trimming.
> 
>> 2) Why was this feature - trimTextNode - introduced in the first place?
> 
> Many of not most of the people who try to use XML Signature screw it up by
> pretty printing documents or believing that whitespace isn't significant.
> 
>> If a party, producing XML, includes some whitespace in a textnode,
>> should C14N just discard it, because it decides that this whitespace
>> must be meaningless?
> 
> It doesn't do that unless the option is enabled, in which case the signer
> knows it's meaningless, right?

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.

I'm trying to imagine a situation in which the use of this attribute is
actually useful, just for the record, to have it documented on the list.

Let's explore the scenario of pretty printing:

The mere fact that the signer sets it to true, indicates that he is very
well aware of the meaning and the specs. So down the chain, he expects
users to mess up the signature by pretty printing.
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. 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.

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.

K.

Received on Tuesday, 20 April 2010 16:56:45 UTC