[xmlsec] XMLSEC Reference URI question
Moultrie, Ferrell (ISSAtlanta)
FMoultrie@iss.net
Thu, 25 Jul 2002 15:48:12 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C23414.35E6B2AA
Content-Type: text/plain
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.
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.
Ferrell
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com]
Sent: Thursday, July 25, 2002 3:10 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec@aleksey.com'; Dodd, Tim (ISS Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
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
<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 <mailto:aleksey@aleksey.com>
]
Sent: Thursday, July 25, 2002 11:43 AM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec@aleksey.com <mailto: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
------_=_NextPart_001_01C23414.35E6B2AA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1050" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D034294619-25072002><FONT face=3DArial =
color=3D#0000ff size=3D2>Thanks=20
for the pointer into the spec and I think we've got this under control =
now.=20
We've got to work out a good XPath transform that works for our =
compound=20
documents but now that I can validate the documents that are produced, =
we can=20
incrementally refine the XPath until we get what we=20
want/need.</FONT></SPAN></DIV>
<DIV><SPAN class=3D034294619-25072002><FONT face=3DArial =
color=3D#0000ff size=3D2>Thanks=20
again for your support -- now I've got a lot of code to write to port =
my stuff=20
from Xerces to libxml and add the signing/verification=20
logic.</FONT></SPAN></DIV>
<DIV><SPAN class=3D034294619-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ferrell</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Aleksey Sanin=20
[mailto:aleksey@aleksey.com] <BR><B>Sent:</B> Thursday, July 25, 2002 =
3:10=20
PM<BR><B>To:</B> Moultrie, Ferrell (ISSAtlanta)<BR><B>Cc:</B>=20
'xmlsec@aleksey.com'; Dodd, Tim (ISS Atlanta)<BR><B>Subject:</B> Re: =
[xmlsec]=20
XMLSEC Reference URI question<BR><BR></FONT></DIV>According to C14N =
spec all=20
whitespaces and eol symbols are preserved.<BR>For example, take a =
look=20
here:<BR> <A class=3Dmoz-txt-link-freetext=20
=
href=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-Whitespa=
ceInContent">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-Whi=
tespaceInContent</A><BR>To=20
be precise, in XML whitespaces are treated as "text" nodes and all =
C14N=20
<BR>regular rules apply to these nodes (for example, you can exclude =
some=20
whitespaces<BR>using XPath expression before C14N, etc.)<BR>I am =
doing my best=20
to make XMLSec library complaint with the specs and<BR>in this =
particular case=20
XMLSec strictly follows the C14N spec by preserving<BR>the =
whitespaces. About=20
the reasons why does it fail, I can add more details for <BR>possible =
options=20
from my previous email (whitespaces were lost in Apache =
and=20
<BR>there are only two possible places :) ):<BR> 1) =
Apache=20
does not treate whitespaces as "text" nodes and by this when=20
<BR> you run XPath expression these missed nodes =
are not=20
included into output<BR> (and not processed by=20
C14N)<BR> 2) Apache does C14N in wrong way and =
removes white=20
spaces<BR><BR><BR>Aleksey<BR><BR><BR>Moultrie, Ferrell (ISSAtlanta) =
wrote:<BR>
<BLOCKQUOTE=20
=
cite=3Dmid121184A7DB1F9143BB5E3FACCB54875703FAD1@atlmaiexcp02.iss.local =
type=3D"cite">
<META content=3D"MSHTML 6.00.2800.1050" name=3DGENERATOR>
<DIV><SPAN class=3D749244918-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Aleksey:</FONT></SPAN></DIV>
<DIV><SPAN class=3D749244918-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2> Ok .. I finally edited the document enough to =
get it to=20
verify. Here's what I had to change -- I haven't had a chance to =
re-read the=20
C14N spec in detail so maybe you can tell me if it's an xmlsec =
problem or=20
not. In order to get it to verify, I removed all the leading =
whitespace=20
(indenting with tabs) from the signed document, I also removed all =
new-line=20
sequences from between the elements in the signed document. So -- =
the C14N=20
transform (or something else in the web world) is removing all the=20
"formatting" (leading tabs and EOL whitespace) from the XML in the =
Apache=20
world. It's obviously preserving that on the xmlsec side based on =
the buffer=20
dump and the fact that manually removing the whitespace works. I'd =
thought=20
that the C14N transform did that for me -- did I miss something or =
is there=20
an issue with the C14N transform in xmlsec. I'm going to go re-read =
the C14N=20
spec now -- but if you can tell me how you think it should behave =
in xmlsec=20
I'd appreciate it!</FONT></SPAN></DIV>
<DIV><SPAN class=3D749244918-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks!</FONT></SPAN></DIV>
<DIV><SPAN class=3D749244918-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2> Ferrell</FONT></SPAN></DIV>
<DIV><SPAN class=3D749244918-25072002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>PS, I'm attaching the original document from the web folks =
(*06.xml,=20
fails) and my edited version (*06a.xml, works).</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Aleksey=20
Sanin [<A class=3Dmoz-txt-link-freetext=20
=
href=3D"mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</A>]=20
<BR><B>Sent:</B> Thursday, July 25, 2002 11:43 AM<BR><B>To:</B> =
Moultrie,=20
Ferrell (ISSAtlanta)<BR><B>Cc:</B> '<A =
class=3Dmoz-txt-link-abbreviated=20
href=3D"mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>'; Dodd, =
Tim (ISS=20
Atlanta)<BR><B>Subject:</B> Re: [xmlsec] XMLSEC Reference URI=20
question<BR><BR></FONT></DIV>After quick look, the XMLSec output =
seems=20
correct. XMLSec produced exactly what <BR>you've seleceted. =
However, the=20
error says that digests do not match and this means that =
<BR>Apache=20
generated another output. I do see few possible=20
options:<BR> 1) Apache calculated wrong nodes =
set (from=20
XPath expressions)<BR> 2) Apache did different =
C14N for=20
the same nodes set<BR> 3) something else more =
stupid on=20
Apache or XMLSec side<BR>I would vote for option 1) since the =
C14N is very=20
simple here (no namespaces, etc.) and <BR>we already have seen =
problems=20
with XPath transform in Apache. But only Apache output<BR>"just =
before=20
digesting" can actually help to identify the =
problem.<BR><BR><BR>With best=20
=
regards,<BR>Aleksey<BR><BR></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></=
BODY></HTML>
------_=_NextPart_001_01C23414.35E6B2AA--