<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2800.1050" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=034294619-25072002><FONT face=Arial color=#0000ff size=2>Thanks
for the pointer into the spec and I think we've got this under control now.
We've got to work out a good XPath transform that works for our compound
documents but now that I can validate the documents that are produced, we can
incrementally refine the XPath until we get what we
want/need.</FONT></SPAN></DIV>
<DIV><SPAN class=034294619-25072002><FONT face=Arial color=#0000ff size=2>Thanks
again for your support -- now I've got a lot of code to write to port my stuff
from Xerces to libxml and add the signing/verification
logic.</FONT></SPAN></DIV>
<DIV><SPAN class=034294619-25072002><FONT face=Arial color=#0000ff
size=2>Ferrell</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Aleksey Sanin
[mailto:aleksey@aleksey.com] <BR><B>Sent:</B> Thursday, July 25, 2002 3:10
PM<BR><B>To:</B> Moultrie, Ferrell (ISSAtlanta)<BR><B>Cc:</B>
'xmlsec@aleksey.com'; Dodd, Tim (ISS Atlanta)<BR><B>Subject:</B> Re: [xmlsec]
XMLSEC Reference URI question<BR><BR></FONT></DIV>According to C14N spec all
whitespaces and eol symbols are preserved.<BR>For example, take a look
here:<BR> <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><BR>To
be precise, in XML whitespaces are treated as "text" nodes and all C14N
<BR>regular rules apply to these nodes (for example, you can exclude some
whitespaces<BR>using XPath expression before C14N, etc.)<BR>I am doing my best
to make XMLSec library complaint with the specs and<BR>in this particular case
XMLSec strictly follows the C14N spec by preserving<BR>the whitespaces. About
the reasons why does it fail, I can add more details for <BR>possible options
from my previous email (whitespaces were lost in Apache and
<BR>there are only two possible places :) ):<BR> 1) Apache
does not treate whitespaces as "text" nodes and by this when
<BR> you run XPath expression these missed nodes are not
included into output<BR> (and not processed by
C14N)<BR> 2) Apache does C14N in wrong way and removes white
spaces<BR><BR><BR>Aleksey<BR><BR><BR>Moultrie, Ferrell (ISSAtlanta) wrote:<BR>
<BLOCKQUOTE
cite=mid121184A7DB1F9143BB5E3FACCB54875703FAD1@atlmaiexcp02.iss.local
type="cite">
<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><SPAN class=749244918-25072002><FONT face=Arial color=#0000ff
size=2> 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!</FONT></SPAN></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></BLOCKQUOTE></BODY></HTML>