> > The only difference that I can see are the missing namespaces. > > That doesn't seem right unless our XML was already indented the same way as > the transform would.
It's the identity transform - that should not do anything except store the DOMSource in a Result. > > No, the problem also occurs if I drop that line (and every other output > > property). Or do you mean the whole transformer approach will not work? > > I have no idea. I certainly believe that's what's breaking it, that or your > c14n afterwards, which isn't guaranteed to work either. You really have > little freedom with the XML, almost anything you do could break the > signature. Isn't the whole idea of XML Signature and Canonicalisation that exactly this should not happen? 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. > No. Once it's trashed, it's probably trashed. > > All you can do is meticulously compare node sets during signing and > verifying, and see why they're different. Either that or have a really good > grasp of c14n and actually eyeball it. Not a solution for me, I fear. The reason I store it to disk and read it back in again is that I cannot transfer a Document object between VMs by serialisation -> see my message "Decryption fails on receiving host, but not on local - pointers?" for this. In essence, what I need is to transfer the XML between sender and receiver. What kind of serialisation would you recommend for the transfer? Ralph -- For contact details, please see www.ralphholz.de.
signature.asc
Description: This is a digitally signed message part.
