RE: Why XML (was: Re: What I see as problems to solve ... and a strawman solution)
"Jim Schaad" <[email protected]> Sun, 8 Feb 2004 21:41:50 -0800
| Newsgroups | gmane.mail.ng |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]] > Sent: Monday, February 02, 2004 11:51 AM > To: [email protected]; [email protected] > 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. >