The problems that I am thinking of are in part outlined by these documents.
But remember that I need to deal with the entire round trip of anything that
modifieds the message. Both the parser and the output code need to not make
and "significant" changes in the data that is being preserved for the
purposes of signing. This generally means that you can't pretty print,
remove any white spaces, the modifying code cannot re-order any nodes, the
modifying code must be sure that it's data is excluded from the signature,
the exclusision information should be signed. (And many other issues.)
I find this to be a very iffy proposition and thus dropped out of the XML
signature specification process.
From: Martin Duerst [mailto:duerst(_at_)w3(_dot_)org]
Sent: Monday, February 02, 2004 11:51 AM
To: jimsch(_at_)exmsft(_dot_)com; mail-ng(_at_)imc(_dot_)org
Subject: RE: Why XML (was: Re: What I see as problems to
solve ... and a strawman solution)
At 14:56 04/02/01 -0800, Jim Schaad wrote:
I would think very carefully before I looked at adopting the XML
signature specification for signing messages, especially if you are
looking at only doing partial signing of documents.
One of the biggest issues that has evolved over the
development of this
specification is the concept of canonicalization. The problem with
this is that many XML parsers play games with whitespace
(lose it, gain
it, combine it, ignore it) and an system where nodes read and write
back out XML on the way to deliver things can cause many
problems of keeping data unchanged.
XML defines exactly what an XML processor (parser) can do and
It's somewhat complicated at first sight, but there are no choices.
Of course, the application on top of the parser may do
whatever it chooses, but that's a different issue. For
details, please see
If different parsers actually give you different whitespace
for the same document, at least one of them is non-conformant.