santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Skip Walker" <>
Subject RE: Java XML C14n interop with .Net
Date Wed, 30 Mar 2005 20:44:19 GMT
Okay, I'm not sure I fully understood, and please excuse my ignorance on a
lot of these matters.

It was my understanding that if I could start with an XML file or String,
use one of the xml parsers to load the file into a Document, and then
produce a canonical version of the xml String using an algorithm implement
in the Apache XML Security package.  I also assumed that I could load, using
C# .NET, the same original XML file, run the same canonicalization algorithm
as was used in the XML Security package in C# (specifically the
XmlDsigC14NWithCommentsTransform) and produce the same canonical xml String
as the Apache Java package produced.  

I was able to accomplish this using the basic Glue 5.0.2/ElectricXML parser
and the XmlDocument object in C#.  

I think what you're saying is that this isn't guaranteed to work if my
parsers are by default collapsing whitespace or doing other data

Should this work if all of the DOMs are set to do no data normalization etc?

Also, what are these &#xD; that appear in both the Glue and C#
canonicalization output?

Also, so I don't have to ask to many dumb questions, is there one resource
that can help me get a handle on these issues.


Skip Walker
Gossamer Group
Bldg #2, Suite 410
4807 Spicewood Springs Rd.
Austin, TX  78759
(512) 342-2600  Fax (512) 342-2612

-----Original Message-----
From: Scott Cantor [] 
Sent: Wednesday, March 30, 2005 12:34 PM
Subject: RE: Java XML C14n interop with .Net

> The canonicalizer produces output that is nothing like the canonicalized
> form produced by .NET and the Glue input based canonicalization:  

They look pretty much the same except for whitespace, but whitespace is
significant. If the XML contains whitespace, c14n doesn't remove it. My
guess is the DOM created by the parsers is different in each case. Different
DOMs mean different c14n octet streams.

You can't set your parser to collapse whitespace, normalize data, etc. if
you want to sign things.

It's common to fool yourself into thinking you can if the parser is the
same, because you're talking to yourself, but once you cross languages, you
can't rely on that and you have to follow the XML rules.

-- Scott

View raw message