Yes, I ran some tests (including the sample
http://www.w3.org/TR/xml-c14n#Example-Chars) and AFAIKS XML Security is
handling the c14n properly. That doesn't necessarily help me much - if
the 1.1 .Net code is broken I'll just have to break my code to be
compatible - but so it goes. I'll post again once the problem is resolved.
- Dennis
Raul Benito wrote:
Well reading the c14n specs in the chapter 1.1 says something
regarding this(see second point below). I think that apache we honour
the point(I will look for a example when I arrive home). So I think
that .NET is having some problems with CR/LF issues.
Anyway if we can help you more don't hesitate in ask more.
And if you manage to arrange the interop send a email to the list for
future reference.
--------------
The canonical form of an XML document is physical representation of
the document produced by the method described in this specification.
The changes are summarized in the following list:
* The document is encoded in UTF-8
* Line breaks normalized to #xA on input, before parsing
* Attribute values are normalized, as if by a validating processor
* Character and parsed entity references are replaced
* CDATA sections are replaced with their character content
* The XML declaration and document type declaration (DTD) are removed
* Empty elements are converted to start-end tag pairs
* Whitespace outside of the document element and within start and
end tags is normalized
* All whitespace in character content is retained (excluding
characters removed during line feed normalization)
* Attribute value delimiters are set to quotation marks (double
quotes)
* Special characters in attribute values and character content are
replaced by character references
* Superfluous namespace declarations are removed from each element
* Default attributes are added to each element
* Lexicographic order is imposed on the namespace declarations and
attributes of each element
On 8/23/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
I'm having problems using XML Security 1.3 (via WSS4J) in talking to
.Net 1.1 code. I get signature errors on the .Net side when the data I'm
sending (and signing) contains embedded CR characters, such as:
<data>a,b,c,d 1,2,3,4 5,6,7,8</data> If I take out the embedded
CRs everything works okay, which makes me suspect it's a
canonicalization issue.
Has anyone else run into this? From a quick glance at the XML Security
code it looks like the canonicalizer is doing the right thing in
converting these to "
" sequences, though I didn't see any tests
that verified proper handling. I saw some discussions on the list last
year that also involved CR, but no resolution.
- Dennis
--
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
