Hmm, well I'm still stuck. Using my test xml file, both Glue and .NET C# both produce all of these 
 elements, while the javax.xml apis produce no 
 entities. If I modify my test xml file to be entirely on one line, this eliminates the line feed problem, but it exposed another problem.
My test message begins like the following <soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' ... The Glue and .NET C# begin <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; ... But the javax.xml begins differently <soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; So the whitespace issue isn't my only problem. Could this be a library issue? Skip Walker [EMAIL PROTECTED] 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 [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 12:34 PM To: security-dev@xml.apache.org; [EMAIL PROTECTED] 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
