[xmlsec] XMLSEC Reference URI question

Thu, 25 Jul 2002 12:10:21 -0700

--------------050004010307090909070006
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

According to C14N spec all whitespaces and eol symbols are preserved.
For example, take a look here:

 http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-WhitespaceInContent
To be precise, in XML whitespaces are treated as "text" nodes and all C14N
regular rules apply to these nodes (for example, you can exclude some 
whitespaces
using XPath expression before C14N, etc.)
I am doing my best to make XMLSec library complaint with the specs and
in this particular case XMLSec strictly follows the C14N spec by preserving
the whitespaces. About the reasons why does it fail, I can add more 
details for
possible options from my previous  email (whitespaces  were lost in 
Apache and
there are only two possible places :) ):
    1) Apache does not treate whitespaces as "text" nodes and by this when
    you run XPath expression these missed nodes are not included into output
    (and not processed by C14N)
    2) Apache does C14N in wrong way and removes white spaces

Aleksey

Moultrie, Ferrell (ISSAtlanta) wrote:

> Aleksey:
>   Ok .. I finally edited the document enough to get it to verify. 
> Here's what I had to change -- I haven't had a chance to re-read the 
> C14N spec in detail so maybe you can tell me if it's an xmlsec problem 
> or not. In order to get it to verify, I removed all the leading 
> whitespace (indenting with tabs) from the signed document, I also 
> removed all new-line sequences from between the elements in the signed 
> document. So -- the C14N transform (or something else in the web 
> world) is removing all the "formatting" (leading tabs and EOL 
> whitespace) from the XML in the Apache world. It's obviously 
> preserving that on the xmlsec side based on the buffer dump and the 
> fact that manually removing the whitespace works. I'd thought that the 
> C14N transform did that for me -- did I miss something or is there an 
> issue with the C14N transform in xmlsec. I'm going to go re-read the 
> C14N spec now -- but if you can tell me how you think it should behave 
> in xmlsec I'd appreciate it!
> Thanks!
>   Ferrell
> PS, I'm attaching the original document from the web folks (*06.xml, 
> fails) and my edited version (*06a.xml, works).
>
>     -----Original Message-----
>     From: Aleksey Sanin [mailto:aleksey@aleksey.com]
>     Sent: Thursday, July 25, 2002 11:43 AM
>     To: Moultrie, Ferrell (ISSAtlanta)
>     Cc: 'xmlsec@aleksey.com'; Dodd, Tim (ISS Atlanta)
>     Subject: Re: [xmlsec] XMLSEC Reference URI question
>
>     After quick look, the XMLSec output seems correct. XMLSec produced
>     exactly what
>     you've seleceted. However, the error says that digests do not
>     match and this means that
>     Apache generated another output. I do see few possible options:
>         1) Apache calculated wrong nodes set (from XPath expressions)
>         2) Apache did different C14N for the same nodes set
>         3) something else more stupid on Apache or XMLSec side
>     I would vote for option 1) since the C14N is very simple here (no
>     namespaces, etc.) and
>     we already have seen problems with XPath transform in Apache. But
>     only Apache output
>     "just before digesting" can actually help to identify the problem.
>
>
>     With best regards,
>     Aleksey
>

--------------050004010307090909070006
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <title></title>
</head>
<body>
According to C14N spec all whitespaces and eol symbols are preserved. 
For example, take a look here: 
ššš š<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-WhitespaceInContent">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-WhitespaceInContent</a> 
To be precise, in XML whitespaces are treated as "text" nodes and all C14N
 
regular rules apply to these nodes (for example, you can exclude some whitespaces 
using XPath expression before C14N, etc.) 
I am doing my best to make XMLSec library complaint with the specs and 
in this particular case XMLSec strictly follows the C14N spec by preserving 
the whitespaces. About the reasons why does it fail, I can add more details
for 
possible options from my previous šemail (whitespaces šwere lost in Apache
and 
there are only two possible places :) ): 
ššš 1) Apache does not treate whitespaces as "text" nodes and by this when
 
ššš you run XPath expression these missed nodes are not included into output 
ššš (and not processed by C14N) 
ššš 2) Apache does C14N in wrong way and removes white spaces 
 
 
Aleksey 
 
 
Moultrie, Ferrell (ISSAtlanta) wrote: 
<blockquote type="cite"
 cite="mid121184A7DB1F9143BB5E3FACCB54875703FAD1@atlmaiexcp02.iss.local">

  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>

  <meta content="MSHTML 6.00.2800.1050" name="GENERATOR">

  <div><span class="749244918-25072002"><font face="Arial"
 color="#0000ff" size="2">Aleksey:</font></span></div>

<div>š Ok .. I finally edited the document enoughšto
get it to verify. Here's what I had to change -- I haven't had a chance
to re-read the C14N spec in detail so maybe you can tell me if it's an xmlsec
problem or not. In order to get it to verify, I removed all the leading
whitespace (indenting with tabs) from the signed document, I also removed
all new-line sequences from between the elements in the signed document.
So -- the C14N transform (or something else in the web world) is removing
all the "formatting" (leading tabs and EOL whitespace) from the XML in the
Apache world. It's obviously preserving that on the xmlsec side based on
the buffer dump and the fact that manually removing the whitespace works.
I'd thought that the C14N transform did that for me -- did I miss something
or is there an issue with the C14N transform in xmlsec. I'm going to go
re-read the C14N spec now -- but if you can tell me how you think it should
 behave in xmlsec I'd appreciate it!</div>

  <div><span class="749244918-25072002"><font face="Arial"
 color="#0000ff" size="2">Thanks!</font></span></div>

  <div><span class="749244918-25072002"><font face="Arial"
 color="#0000ff" size="2">š  Ferrell</font></span></div>

  <div><span class="749244918-25072002"><font face="Arial"
 color="#0000ff" size="2">PS,  I'm attaching the original document from the
web folks (*06.xml, fails) and my  edited version (*06a.xml, works).</font></span></div>

  <blockquote style="margin-right: 0px;">      
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Aleksey Sanin    [<a class="moz-txt-link-freetext" href="mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</a>] <br>
    <b>Sent:</b> Thursday, July 25, 2002 11:43    AM<br>
    <b>To:</b> Moultrie, Ferrell (ISSAtlanta)<br>
    <b>Cc:</b>    '<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>'; Dodd, Tim (ISS Atlanta)<br>
    <b>Subject:</b> Re: [xmlsec]    XMLSEC Reference URI question<br>
    <br>
    </font></div>
After quick look, the XMLSec    output seems correct. XMLSec produced exactly
what <br>
you've seleceted.    However, the error says that digests do not match and
this means that    <br>
Apache generated another output. I do see few possible    options:<br>
ššš 1) Apache calculated wrong nodes set (from    XPath expressions)<br>
ššš 2) Apache did different C14N for the    same nodes set<br>
ššš 3) something else more stupid on Apache    or XMLSec side<br>
I would vote for option 1) since the C14N is very simple    here (no namespaces,
etc.) and <br>
we already have seen problems with XPath    transform in Apache. But only
Apache output<br>
"just before digesting" can    actually help to identify the problem.<br>
    <br>
    <br>
With best    regards,<br>
Aleksey<br>
    <br>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------050004010307090909070006--