santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Cantor" <canto...@osu.edu>
Subject RE: Signature breaks during I/O and parsing, but cannot resolve with canonicalisation
Date Thu, 06 Dec 2007 16:39:03 GMT
> It's the identity transform - that should not do anything except store the
> DOMSource in a Result.

Not if you're pretty printing with some kind of indent flag. That can't possibly do what it
says if it's really an identity transform....

> Isn't the whole idea of XML Signature and Canonicalisation that exactly this
> should not happen?

Yes, but they don't work well, and it very much depends on namespace handling and the specifics
of your document whether you'll break something by running it through a c14n step yourself.
That can affect the namespaces in a destructive manner depending on the c14n the signature
or reference(s) are using. Many serializers also affect namespaces in odd ways.

> When I hand XML over to some HTTP agent, there are almost
> certainly small changes (linefeeds etc.) that happen on the way to the
> destination.

If you change the whitespace, you're dead. None of the standard c14n algorithms will handle
that. Whitespace is significant in XML, so it *will* change the digest. This is often surprising
to people, but it's true. If you have some way to recover the original XML by knowing what
whitespace was added or removed, then sure, you could deal with it, but in effect that's like
having a new c14n or transform algorithm.

> In essence, what I need is to transfer the XML between sender and receiver.
> What kind of serialisation would you recommend for the transfer?

I definitely wouldn't use code that was likely to affect the DOM in any way. I would simply
write out the DOM node by node using a serializer that was designed to do nothing else to
it. Namespaces are another matter...it's often necessary to have a layer of code that handles
namespace declarations up front so that the serializer isn't responsible for guaranteeing
well-formedness.

And that doesn't even cover extension namespace issues, xsi:types, and so forth, where c14n
itself has problems. My project has an entire library layer around DOM and xmlsec to address
that stuff.

But you have to be *very* certain about no whitespace changes, above all else. That's the
one thing we know will break it. That can have implications for your parser, of course, since
you don't want it collapsing whitespace, and schema normalization will also affect linefeeds
(not that you're validating, but it's an example).

-- Scott



Mime
View raw message