mail-ng
[Top] [All Lists]

RE: Why XML (was: Re: What I see as problems to solve ... and a strawman solution)

2004-02-08 22:37:31

 Martin,

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.

jim

-----Original Message-----
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 
what not.
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 
http://www.w3.org/TR/REC-xml#sec-white-space and 
http://www.w3.org/TR/REC-xml#sec-line-ends.

If different parsers actually give you different whitespace 
for the same document, at least one of them is non-conformant.

Regards,   Martin.