santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: .Net interop problem
Date Thu, 24 Aug 2006 19:54:07 GMT
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 <dms@sosnoski.com> 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&#13;1,2,3,4&#13;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 "&#xD;" 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
>>
>>
>
>

Mime
View raw message