[xmlsec] XMLSEC Reference URI question
Moultrie, Ferrell (ISSAtlanta)
FMoultrie@iss.net
Thu, 25 Jul 2002 14:55:44 -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_000_01C2340C.E13F08A5
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C2340C.E13F08A5"
------_=_NextPart_001_01C2340C.E13F08A5
Content-Type: text/plain
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
Moultrie, Ferrell (ISSAtlanta) wrote:
Aleksey:
Ok .. we've reworked the XPath and xmlsec's buffer start/end now shows the
correct data (only the selected Contact key and the <Signature> block is
omittied). Still, it won't verify. I'd greatly appreciate it if you could
take one more look and see if you see any other reasons why things might not
be working as expected. The command used was:
xmlsec verify --print-all --trusted new_export.pem test_allkey_06.xml
I've attached the XML file, the PubKey cert and the program output. I'm also
trying to find out if the signing stuff on the web server can provide any
more details on what/how it did when building the signature -- but I've
never touched any of that stuff so I'm having to work through our web folks
for that information.
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com <mailto:aleksey@aleksey.com>
]
Sent: Wednesday, July 24, 2002 10:23 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec@aleksey.com <mailto:xmlsec@aleksey.com> '; Dodd, Tim (ISS
Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
Well, "failing to validate reference" simply means that the digests values
do not
match. In this particular case, when Apache calculated digested the c14n
output
both digest and signature values (content of <dsig:DigestValue> and
<dsig:SignatureValue>
elements) were *not known* yet. Since as we found this XPath transform
includes
*all* nodes from the input document when you are veryfing the document,
both <dsig:DigestValue> and <dsig:SignatureValue> elements (and the content
of these
elements: the actual base64 encoded digest and signature values!) are
*included*
in the digested data.
And of course, the "sign" and "verify" digests are different because the
digested
data are different :)
This explains why XMLSec fails to validate this document and also shows that
any *correct* implementation of XPath transform MUST fail to validate it.
Since you wrote that Apache has no problems with validating this document I
suspect
that Apache does not implement the XPath transform correctly :)
Probably you can find our more if you can get the c14n output (just before
digesting)
from Apache (something similar to --print-all option in xmlsec). I am sorry
but
I could not help you with it since I gave up on installing Apache toolkit
long time ago (this
was the main reason why I wrote XMLSec library :) ).
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
Aleksey:
Yes -- you're right. I even recall reading a discussion about this in the
discussion of enveloped signatures in the specification. I wondered at the
time why they used the convoluted XPath count function rather than a more
direct approach -- now I get it.
In any event - I suspect that Apache is actually still signing/verifying
the entire document just like XMLSEC is *trying* to do. So .. I should be
able to verify this document also using XMLSEC. Do you have any idea from
the sample our it's output as to why it fails to validate the Reference?
This is *always* the hard part of digital signature work -- when it doesn't
work -- figuring out *why* it failed. What bit is wrong where ...
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com <mailto:aleksey@aleksey.com>
]
Sent: Wednesday, July 24, 2002 9:22 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec@aleksey.com <mailto:xmlsec@aleksey.com> '; Dodd, Tim (ISS
Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
Hi, Moultrie!
I think that there is a "bug" in the document you provided and Apache
toolkit incorrectly implemented XPath transform. According to the XMLDSig
spec (http://www.w3.org/TR/xmldsig-core/#sec-XPath
<http://www.w3.org/TR/xmldsig-core/#sec-XPath> ) the XPath transform
is evaluated as follows:
> In other words, the input node-set should be equivalent to the one
that would be created by
> the following process:
> 1. Initialize an XPath evaluation context by setting the initial
node equal to the input XML
> document's root node, and set the context position and size to 1.
> 2. Evaluate the XPath expression (//. | //@* | //namespace::*)
> The evaluation of this expression includes all of the document's nodes
(including comments) in the
> node-set representing the octet stream.
> The transform output is also an XPath node-set. The XPath expression
appearing in the XPath
> parameter is evaluated once for each node in the input node-set. The
result is converted to a
> boolean. If the boolean is true, then the node is included in the
output node-set. If the boolean is
> false, then the node is omitted from the output node-set.
In our case, the XPath expression in the XPath parameter is
"/ISSKeys/Contacts/Contact"
Evaluating this XPath expression returns a non-empty node set and according
to the
XPath spec (http://www.w3.org/TR/1999/REC-xpath-19991116#booleans
<http://www.w3.org/TR/1999/REC-xpath-19991116#booleans> ) it is converted
to boolean by a call to the boolean() function. From the same spec,
(http://www.w3.org/TR/1999/REC-xpath-19991116#function-boolean
<http://www.w3.org/TR/1999/REC-xpath-19991116#function-boolean> )
the boolean() function *always* returns true for non-empty node set:
> a node-set is true if and only if it is non-empty
For the document you sent me, this means that the XPath expression from the
XPath
parameter will be "true" for *all* nodes and *all* nodes should be included
in the output.
And this is exactly what XMLSec library returns!
I totally agree with you that such behavior is absolutely not intuitive and
can cause errors.
XMLDSig working group is now developing a new XPath transform spec (XPath
filter 2) and
this particular issue is fixed there. However, this new spec is not stable
right now and changes
almost every day so I could not recommend to use it in production yet.
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
xmlsec verify --print-all --trusted new_export.pem test_allkey_04.xml
I've included the PEM-formatted public key, the XML test document and the
output captured from running the 07/12/02 build of xmlsec plus the one fix
you sent me earlier. Let me know if you need anything else.
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com <mailto:aleksey@aleksey.com>
]
Sent: Wednesday, July 24, 2002 5:48 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec@aleksey.com <mailto:xmlsec@aleksey.com> '; Dodd, Tim (ISS
Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
I am not sure I clear understand what kind of problem do you have. Will you
mind to send me the file you have problems with?
Thanks,
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
Aleksey:
Ok, I've tried to use an XPath Transform to limit the data being
verified. Unfortunately, it doesn't appear to work. Here's what I see
happening in the
code:
xmlSecTransformXPathReadNode( ) [xpath.c:203] takes the input
xmlSecTransformPtr and upcasts it to a xmlSecXmlTransformPtr. It then
stores the parsed XPath string and the "here" node reference in the
xmlSecXmlTransform object it points to (at least there's checking of
the pointer assignment sanity here).
The caller, xmlSecTransformRead, returns to its caller
xmlSecTransformNodeRead with the pointer to the object containing the
XPath transform information. The transform is further passed back to
xmlSecTransformsNodeRead which calls xmlSecTransformStateUpdate which
discovers that the transform type is xmlSecTransformTypeXml and call
xmlSecTransformCreateXml. This routine, because the file is already
parsed and both curFirstBinTransform and curC14NTransform in the state
object are NULL, does nothing and returns!
This results in the XPath Transform information being parsed and saved
but otherwise ignored. The <Signature> block contains the following
transform which is parsed and ignored in the above case:
<sig:Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
<http://www.w3.org/TR/1999/REC-xpath-19991116> >
<sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
</sig:Transform>
The result is that adding an XPath transform like above, is ignored.
This works properly with the Apache Java tools so I believe that it's a
legal way to construct a reference. Eventually, I'd intended to change
the XPath reference to a here()-relative reference to solve my compound
document problem but this seemed like a quick/easy test --
unfortunately it's not working.
Is this a bug, or, have I missed something else? Since Apache properly
verifies this signature and the code in xmlSecTransformCreateXml seems
to be missing any knowledge of this transform, I'm guessing that it's a
bug -- but I'll appreciate your advice on how to proceed!
Thanks!
Ferrell
=====================================
Ferrell Moultrie (ferrell@iss.net <mailto:ferrell@iss.net> )
Software Engineer
Internet Security Systems, Inc.
6303 Barfield Road
Atlanta, Georgia 30328
Phone: 404-236-2600
Direct: 404-236-2849
Fax: 404-236-2632
http://www.iss.net <http://www.iss.net>
Internet Security Systems -- The Power to Protect
=====================================
_______________________________________________
xmlsec mailing list
xmlsec@aleksey.com <mailto:xmlsec@aleksey.com>
http://www.aleksey.com/mailman/listinfo/xmlsec
<http://www.aleksey.com/mailman/listinfo/xmlsec>
_____
xmlSecSignedInfoRead: failed to validate "Reference"
= XMLDSig Result (validate)
== result: FAIL
== sign method: http://www.w3.org/2000/09/xmldsig#rsa-sha1
<http://www.w3.org/2000/09/xmldsig#rsa-sha1>
== KEY
=== method: RSAKeyValue
=== key name: NULL
=== key type: Public
=== key origin: x509
=== X509 Certificate
==== Subject Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Serial: 3CEF18C2
== SIGNED INFO REFERENCES
=== REFERENCE
==== ref type: SignedInfo Reference
==== result: FAIL
==== digest method: http://www.w3.org/2000/09/xmldsig#sha1
<http://www.w3.org/2000/09/xmldsig#sha1>
==== uri:
==== type: NULL
==== id: NULL
==== start buffer:
<ISSKeys Source="ISS Atlanta">
<Contacts>
<Contact>
<Keys Address1="2626 Somewhere Lane" Address2="suite
200A" City="Atlanta" Country="US" Email="keys@iss.net" <mailto:keys@iss.net>
Fax="778-555-1212" Phone="777.555.1212" PostCode="30064"
Weburl="http://web.fubar.net" <http://web.fubar.net> ></Keys>
<CustomerRelations Address1="1313 k nowwhere Lane"
Address2="suite 300A" City="Atlanta" Country="US"
Email="customer_relations@iss.net" <mailto:customer_relations@iss.net>
Fax="778-555-7799" Phone="77 7.555.7788" PostCode="30064"
Weburl="http://web.customer_relations_iss.net"
<http://web.customer_relations_iss.net> ></CustomerRelations>
<Support Address1="1234 Anvil Rd." Address2="suite
440B" City="Atlanta" Country="US" Email="support@iss.net"
<mailto:support@iss.net> Fax="778-555-7755" Phone="777.555.7744"
PostCode="3 0064" Weburl="http://web.suport_iss.net"
<http://web.suport_iss.net> ></Support>
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>AC
C64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
<sig:Signature
xmlns:sig="http://www.w3.org/2000/09/xmldsig#"
<http://www.w3.org/2000/09/xmldsig#> >
<sig:SignedInfo>
<sig:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>
></sig:CanonicalizationMethod>
<sig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
<http://www.w3.org/2000/09/xmldsig#rsa-sha1> ></sig:SignatureMethod>
<sig:Reference URI="">
<sig:Transforms>
<sig:Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
<http://www.w3.org/TR/1999/REC-xpath-19991116> >
<sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
</sig:Transform>
<sig:Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments>
></sig:Transform>
</sig:Transforms>
<sig:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
<http://www.w3.org/2000/09/xmldsig#sha1> ></sig:DigestMethod>
<sig:DigestValue>3tPX5xUmcKYHkG3Mv8TBAAYjBIU=</sig:DigestValue>
</sig:Reference>
</sig:SignedInfo>
<sig:SignatureValue>GpbCX9juwQ6k4Hs5j19MSXdtAdxeY9cK06Hb17ugq7f6sIy71gafWWNJ
1Na/TKGCrABlgrXWH2VR
asYcPMEmi1RZKDPUzmPAjznKRozjZTS3nn2BrAl1EKLugiqYmer+IG8SOXXTDSiwbmphtsXK+emU
FpUVVxfjLrmk8h6hd4k=</sig:SignatureValue>
<sig:KeyInfo>
<sig:X509Data>
<sig:X509Certificate>
MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVdl
YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhcNMDIw
NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2ViIERl
dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mM
uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JT
nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBy
08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+CuyIK
wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0FSlg8c
GL2eqXYylPEeMvZ5aw==
</sig:X509Certificate>
</sig:X509Data>
<sig:KeyValue>
<sig:RSAKeyValue>
<sig:Modulus>
y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0QS7Re
D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc38gfE
EkEJnS4iCzUC7WHsNgM=
</sig:Modulus>
<sig:Exponent>AQAB</sig:Exponent>
</sig:RSAKeyValue>
</sig:KeyValue>
</sig:KeyInfo>
</sig:Signature>
</Contact>
</Contacts>
<EndUsers>
<EndUser Address1="666 Rockets way" Address2="Apt. B"
City="Scienceville" CompanyName="Spacely Sprockets" Country="US"
Email="gjetson@sprokets.net" <mailto:gjetson@sprokets.net> PostCode=""
State="Disturbed" SubjectName=FAIL
"George Jetson" Title="Whipping Boy">
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6A
E</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</EndUser>
</EndUsers>
<LicensedModules>
<LicensedModule ContactInfo="ACC64BB4-
A53D-AC83-3E6F-E0AB737DEC9D"
EndUserInfo="CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity="RO"
LicenseExpiration="2003-06-14" LicenseType="evaluation" Limit="2147483647"
LimitOutOfMaintenance="0" MaintenanceExpiration="2003-06-14">
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</LicensedModule>
</LicensedModules>
</ISSKeys>
==== end buffer:
= Status:
== Signatures ok: 0
== Signatures fail: 1
== SignedInfo Ref ok: 0
== SignedInfo Ref fail: 1
== Manifest Ref ok: 0
== Manifest Ref fail: 0
Error: operation failed
_____
FAIL
xmlSecSignedInfoRead: failed to validate "Reference"
= XMLDSig Result (validate)
== result: FAIL
== sign method: http://www.w3.org/2000/09/xmldsig#rsa-sha1
<http://www.w3.org/2000/09/xmldsig#rsa-sha1>
== KEY
=== method: RSAKeyValue
=== key name: NULL
=== key type: Public
=== key origin: x509
=== X509 Certificate
==== Subject Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Serial: 3CEF18C2
== SIGNED INFO REFERENCES
=== REFERENCE
==== ref type: SignedInfo Reference
==== result: FAIL
==== digest method: http://www.w3.org/2000/09/xmldsig#sha1
<http://www.w3.org/2000/09/xmldsig#sha1>
==== uri:
==== type: NULL
==== id: NULL
==== start buffer:
<Contact>
<Keys Address1="2626 Somewhere Lane" Address2="suite
200A" City="Atlanta" Country="US" Email="keys@iss.net" <mailto:keys@iss.net>
Fax="778-555-1212" Phone="777.555.1212" PostCode="30064"
Weburl="http://web.fubar.net" <http://web.fubar.net> ></Keys>
<CustomerRelations Address1="1313 knowwhere Lane"
Address2="suite 300A" City="Atlanta" Country="US"
Email="customer_relations@iss.net" <mailto:customer_relations@iss.net>
Fax="778-555-7799" Phone="777.555.7788" PostCode="30064"
Weburl="http://web.customer_relations_iss.net"
<http://web.customer_relations_iss.net> ></CustomerRelations>
<Support Address1="1234 Anvil Rd." Address2="suite
440B" City="Atlanta" Country="US" Email="support@iss.net"
<mailto:support@iss.net> Fax="778-555-7755" Phone="777.555.7744"
PostCode="30064" Weburl="http://web.suport_iss.net"
<http://web.suport_iss.net> ></Support>
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</Contact>
==== end buffer:
= Status:
== Signatures ok: 0
== Signatures fail: 1
== SignedInfo Ref ok: 0
== SignedInfo Ref fail: 1
== Manifest Ref ok: 0
== Manifest Ref fail: 0
Error: operation failed
------_=_NextPart_001_01C2340C.E13F08A5
Content-Type: text/html
<!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=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></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 11:43
AM<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>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><BR><BR>Moultrie, Ferrell (ISSAtlanta) wrote:<BR>
<BLOCKQUOTE
cite=mid121184A7DB1F9143BB5E3FACCB54875703FACC@atlmaiexcp02.iss.local
type="cite">
<META content="MSHTML 6.00.2800.1050" name=GENERATOR>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2>Aleksey:</FONT></SPAN></DIV>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2> Ok .. we've reworked the XPath and xmlsec's buffer start/end
now shows the correct data (only the selected Contact key and the
<Signature> block is omittied). Still, it won't verify. I'd greatly
appreciate it if you could take one more look and see if you see any other
reasons why things might not be working as expected. The command used
was:</FONT></SPAN></DIV>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2>xmlsec verify --print-all --trusted new_export.pem
test_allkey_06.xml</FONT></SPAN></DIV>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2>I've attached the XML file, the PubKey cert and the program output.
I'm also trying to find out if the signing stuff on the web server can
provide any more details on what/how it did when building the signature --
but I've never touched any of that stuff so I'm having to work through our
web folks for that information.</FONT></SPAN></DIV>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2>Thanks!</FONT></SPAN></DIV>
<DIV><SPAN class=471475413-25072002><FONT face=Arial color=#0000ff
size=2> Ferrell</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> Wednesday, July 24, 2002 10:23 PM<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>Well, "failing to validate reference" simply
means that the digests values do not <BR>match. In this particular case,
when Apache calculated digested the c14n output<BR>both digest and
signature values (content of <dsig:DigestValue> and
<dsig:SignatureValue><BR>elements) were *not known* yet. Since
as we found this XPath transform includes <BR>*all* nodes from the input
document when you are veryfing the document, <BR>both
<dsig:DigestValue> and <dsig:SignatureValue> elements (and the
content of these<BR>elements: the actual base64 encoded digest and
signature values!) are *included* <BR>in the digested data. <BR>And of
course, the "sign" and "verify" digests are different because the digested
<BR>data are different :)<BR><BR>This explains why XMLSec fails to
validate this document and also shows that <BR>any *correct*
implementation of XPath transform MUST fail to validate it.<BR>Since you
wrote that Apache has no problems with validating this document I suspect
<BR>that Apache does not implement the XPath transform correctly
:)<BR><BR>Probably you can find our more if you can get the c14n output
(just before digesting)<BR>from Apache (something similar to --print-all
option in xmlsec). I am sorry but<BR>I could not help you with it since I
gave up on installing Apache toolkit long time ago (this <BR>was the main
reason why I wrote XMLSec library :)
).<BR><BR>Aleksey<BR><BR><BR><BR><BR>Moultrie, Ferrell (ISSAtlanta)
wrote:<BR>
<BLOCKQUOTE
cite=mid121184A7DB1F9143BB5E3FACCB54875703FAC8@atlmaiexcp02.iss.local
type="cite">
<META content="MSHTML 6.00.2800.1050" name=GENERATOR>
<DIV><SPAN class=538434501-25072002><FONT face=Arial color=#0000ff
size=2>Aleksey:</FONT></SPAN></DIV>
<DIV><SPAN class=538434501-25072002><FONT face=Arial color=#0000ff
size=2> Yes -- you're right. I even recall reading a discussion
about this in the discussion of enveloped signatures in the
specification. I wondered at the time why they used the convoluted XPath
count function rather than a more direct approach -- now I get it.
</FONT></SPAN></DIV>
<DIV><SPAN class=538434501-25072002><FONT face=Arial color=#0000ff
size=2> In any event - I suspect that Apache is actually still
signing/verifying the entire document just like XMLSEC is *trying* to
do. So .. I should be able to verify this document also using XMLSEC. Do
you have any idea from the sample our it's output as to why it fails to
validate the Reference? This is *always* the hard part of digital
signature work -- when it doesn't work -- figuring out *why* it failed.
What bit is wrong where ...</FONT></SPAN></DIV>
<DIV><SPAN class=538434501-25072002><FONT face=Arial color=#0000ff
size=2>Thanks!</FONT></SPAN></DIV>
<DIV><SPAN class=538434501-25072002><FONT face=Arial color=#0000ff
size=2> Ferrell</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> Wednesday, July 24, 2002 9:22 PM<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>Hi, Moultrie!<BR><BR>I think that there
is a "bug" in the document you provided and Apache<BR>toolkit
incorrectly implemented XPath transform. According to the XMLDSig
<BR>spec (<A class=moz-txt-link-freetext
href="http://www.w3.org/TR/xmldsig-core/#sec-XPath">http://www.w3.org/TR/xmldsig-core/#sec-XPath</A>)
the XPath transform<BR>is evaluated as
follows:<BR><BR> > In other words, the input
node-set should be equivalent to the one that would be created by
<BR> > the following
process:<BR> > 1. Initialize an XPath
evaluation context by setting the initial node equal to the input XML
<BR> > document's root node, and set the
context position and size to 1.<BR> > 2.
Evaluate the XPath expression <CODE>(//. | //@* |
//namespace::*)</CODE><BR> > The evaluation of
this expression includes all of the document's nodes (including
comments) in the <BR> > node-set representing the
octet stream.<BR> > The transform output is also
an XPath node-set. The XPath expression appearing in the
<CODE>XPath</CODE> <BR> > parameter is evaluated
once for each node in the input node-set. The result is converted to a
<BR> > boolean. If the boolean is true, then the
node is included in the output node-set. If the boolean is
<BR> > false, then the node is omitted from the
output node-set. <BR><BR>In our case, the XPath expression in the
XPath parameter is "/ISSKeys/Contacts/Contact"<BR>Evaluating this
XPath expression returns a non-empty node set and according to the
<BR>XPath spec (<A class=moz-txt-link-freetext
href="http://www.w3.org/TR/1999/REC-xpath-19991116#booleans">http://www.w3.org/TR/1999/REC-xpath-19991116#booleans</A>)
it is converted <BR>to boolean by a call to the boolean() function.
From the same spec, (<A class=moz-txt-link-freetext
href="http://www.w3.org/TR/1999/REC-xpath-19991116#function-boolean">http://www.w3.org/TR/1999/REC-xpath-19991116#function-boolean</A>)
<BR>the boolean() function *always* returns true for non-empty node
set:<BR> > a node-set is true if and only
if it is non-empty <BR>For the document you sent me, this means that
the XPath expression from the XPath <BR>parameter will be "true"
for *all* nodes and *all* nodes should be included in the
output.<BR>And this is exactly what XMLSec library returns!<BR><BR>I
totally agree with you that such behavior is absolutely not intuitive
and can cause errors.<BR>XMLDSig working group is now developing a new
XPath transform spec (XPath filter 2) and <BR>this particular issue is
fixed there. However, this new spec is not stable right now and
changes<BR>almost every day so I could not recommend to use it in
production yet. <BR><BR><BR>Aleksey<BR><BR><BR><BR>Moultrie, Ferrell
(ISSAtlanta) wrote:<BR>
<BLOCKQUOTE
cite=mid121184A7DB1F9143BB5E3FACCB54875703FAC4@atlmaiexcp02.iss.local
type="cite"><PRE wrap="">xmlsec verify --print-all --trusted new_export.pem test_allkey_04.xml
I've included the PEM-formatted public key, the XML test document and the
output captured from running the 07/12/02 build of xmlsec plus the one fix
you sent me earlier. Let me know if you need anything else.
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [<A class=moz-txt-link-freetext href="mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</A>]
Sent: Wednesday, July 24, 2002 5:48 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: '<A class=moz-txt-link-abbreviated href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>'; Dodd, Tim (ISS Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
I am not sure I clear understand what kind of problem do you have. Will you
mind to send me the file you have problems with?
Thanks,
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Aleksey:
Ok, I've tried to use an XPath Transform to limit the data being
verified. Unfortunately, it doesn't appear to work. Here's what I see
happening in the
code:
xmlSecTransformXPathReadNode( ) [xpath.c:203] takes the input
xmlSecTransformPtr and upcasts it to a xmlSecXmlTransformPtr. It then
stores the parsed XPath string and the "here" node reference in the
xmlSecXmlTransform object it points to (at least there's checking of
the pointer assignment sanity here).
The caller, xmlSecTransformRead, returns to its caller
xmlSecTransformNodeRead with the pointer to the object containing the
XPath transform information. The transform is further passed back to
xmlSecTransformsNodeRead which calls xmlSecTransformStateUpdate which
discovers that the transform type is xmlSecTransformTypeXml and call
xmlSecTransformCreateXml. This routine, because the file is already
parsed and both curFirstBinTransform and curC14NTransform in the state
object are NULL, does nothing and returns!
This results in the XPath Transform information being parsed and saved
but otherwise ignored. The <Signature> block contains the following
transform which is parsed and ignored in the above case:
<sig:Transform
Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/TR/1999/REC-xpath-19991116">"http://www.w3.org/TR/1999/REC-xpath-19991116"</A>>
<sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
</sig:Transform>
The result is that adding an XPath transform like above, is ignored.
This works properly with the Apache Java tools so I believe that it's a
legal way to construct a reference. Eventually, I'd intended to change
the XPath reference to a here()-relative reference to solve my compound
document problem but this seemed like a quick/easy test --
unfortunately it's not working.
Is this a bug, or, have I missed something else? Since Apache properly
verifies this signature and the code in xmlSecTransformCreateXml seems
to be missing any knowledge of this transform, I'm guessing that it's a
bug -- but I'll appreciate your advice on how to proceed!
Thanks!
Ferrell
=====================================
Ferrell Moultrie (<A class=moz-txt-link-abbreviated href="mailto:ferrell@iss.net">ferrell@iss.net</A>)
Software Engineer
Internet Security Systems, Inc.
6303 Barfield Road
Atlanta, Georgia 30328
Phone: 404-236-2600
Direct: 404-236-2849
Fax: 404-236-2632
<A class=moz-txt-link-freetext href="http://www.iss.net">http://www.iss.net</A>
Internet Security Systems -- The Power to Protect
=====================================
_______________________________________________
xmlsec mailing list
<A class=moz-txt-link-abbreviated href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A> <A class=moz-txt-link-freetext href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE><PRE wrap=""><HR width="90%" SIZE=4>
xmlSecSignedInfoRead: failed to validate "Reference"
= XMLDSig Result (validate)
== result: FAIL
== sign method: <A class=moz-txt-link-freetext href="http://www.w3.org/2000/09/xmldsig#rsa-sha1">http://www.w3.org/2000/09/xmldsig#rsa-sha1</A>
== KEY
=== method: RSAKeyValue
=== key name: NULL
=== key type: Public
=== key origin: x509
=== X509 Certificate
==== Subject Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Serial: 3CEF18C2
== SIGNED INFO REFERENCES
=== REFERENCE
==== ref type: SignedInfo Reference
==== result: FAIL
==== digest method: <A class=moz-txt-link-freetext href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</A>
==== uri:
==== type: NULL
==== id: NULL
==== start buffer:
<ISSKeys Source="ISS Atlanta">
<Contacts>
<Contact>
<Keys Address1="2626 Somewhere Lane" Address2="suite 200A" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:keys@iss.net">"keys@iss.net"</A> Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.fubar.net">"http://web.fubar.net"</A>></Keys>
<CustomerRelations Address1="1313 k nowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:customer_relations@iss.net">"customer_relations@iss.net"</A> Fax="778-555-7799" Phone="77 7.555.7788" PostCode="30064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.customer_relations_iss.net">"http://web.customer_relations_iss.net"</A>></CustomerRelations>
<Support Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:support@iss.net">"support@iss.net"</A> Fax="778-555-7755" Phone="777.555.7744" PostCode="3 0064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.suport_iss.net">"http://web.suport_iss.net"</A>></Support>
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>AC
C64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
<sig:Signature xmlns:sig=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/2000/09/xmldsig#">"http://www.w3.org/2000/09/xmldsig#"</A>>
<sig:SignedInfo>
<sig:CanonicalizationMethod Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">"http://www.w3.org/TR/2001/REC-xml-c14n-20010315"</A>></sig:CanonicalizationMethod>
<sig:SignatureMethod Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/2000/09/xmldsig#rsa-sha1">"http://www.w3.org/2000/09/xmldsig#rsa-sha1"</A>></sig:SignatureMethod>
<sig:Reference URI="">
<sig:Transforms>
<sig:Transform Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/TR/1999/REC-xpath-19991116">"http://www.w3.org/TR/1999/REC-xpath-19991116"</A>>
<sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
</sig:Transform>
<sig:Transform Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments">"http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"</A>></sig:Transform>
</sig:Transforms>
<sig:DigestMethod Algorithm=<A class=moz-txt-link-rfc2396E href="http://www.w3.org/2000/09/xmldsig#sha1">"http://www.w3.org/2000/09/xmldsig#sha1"</A>></sig:DigestMethod>
<sig:DigestValue>3tPX5xUmcKYHkG3Mv8TBAAYjBIU=</sig:DigestValue>
</sig:Reference>
</sig:SignedInfo>
<sig:SignatureValue>GpbCX9juwQ6k4Hs5j19MSXdtAdxeY9cK06Hb17ugq7f6sIy71gafWWNJ1Na/TKGCrABlgrXWH2VR
asYcPMEmi1RZKDPUzmPAjznKRozjZTS3nn2BrAl1EKLugiqYmer+IG8SOXXTDSiwbmphtsXK+emU
FpUVVxfjLrmk8h6hd4k=</sig:SignatureValue>
<sig:KeyInfo>
<sig:X509Data>
<sig:X509Certificate>
MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVdl
YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhcNMDIw
NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2ViIERl
dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mM
uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JT
nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBy
08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+CuyIK
wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0FSlg8c
GL2eqXYylPEeMvZ5aw==
</sig:X509Certificate>
</sig:X509Data>
<sig:KeyValue>
<sig:RSAKeyValue>
<sig:Modulus>
y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0QS7Re
D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc38gfE
EkEJnS4iCzUC7WHsNgM=
</sig:Modulus>
<sig:Exponent>AQAB</sig:Exponent>
</sig:RSAKeyValue>
</sig:KeyValue>
</sig:KeyInfo>
</sig:Signature>
</Contact>
</Contacts>
<EndUsers>
<EndUser Address1="666 Rockets way" Address2="Apt. B" City="Scienceville" CompanyName="Spacely Sprockets" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:gjetson@sprokets.net">"gjetson@sprokets.net"</A> PostCode="" State="Disturbed" SubjectName=FAIL
"George Jetson" Title="Whipping Boy">
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6A
E</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</EndUser>
</EndUsers>
<LicensedModules>
<LicensedModule ContactInfo="ACC64BB4- A53D-AC83-3E6F-E0AB737DEC9D" EndUserInfo="CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity="RO" LicenseExpiration="2003-06-14" LicenseType="evaluation" Limit="2147483647" LimitOutOfMaintenance="0" MaintenanceExpiration="2003-06-14">
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</LicensedModule>
</LicensedModules>
</ISSKeys>
==== end buffer:
= Status:
== Signatures ok: 0
== Signatures fail: 1
== SignedInfo Ref ok: 0
== SignedInfo Ref fail: 1
== Manifest Ref ok: 0
== Manifest Ref fail: 0
Error: operation failed
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE><PRE wrap=""><HR width="90%" SIZE=4>
FAIL
xmlSecSignedInfoRead: failed to validate "Reference"
= XMLDSig Result (validate)
== result: FAIL
== sign method: <A class=moz-txt-link-freetext href="http://www.w3.org/2000/09/xmldsig#rsa-sha1">http://www.w3.org/2000/09/xmldsig#rsa-sha1</A>
== KEY
=== method: RSAKeyValue
=== key name: NULL
=== key type: Public
=== key origin: x509
=== X509 Certificate
==== Subject Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
==== Issuer Serial: 3CEF18C2
== SIGNED INFO REFERENCES
=== REFERENCE
==== ref type: SignedInfo Reference
==== result: FAIL
==== digest method: <A class=moz-txt-link-freetext href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</A>
==== uri:
==== type: NULL
==== id: NULL
==== start buffer:
<Contact>
<Keys Address1="2626 Somewhere Lane" Address2="suite 200A" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:keys@iss.net">"keys@iss.net"</A> Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.fubar.net">"http://web.fubar.net"</A>></Keys>
<CustomerRelations Address1="1313 knowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:customer_relations@iss.net">"customer_relations@iss.net"</A> Fax="778-555-7799" Phone="777.555.7788" PostCode="30064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.customer_relations_iss.net">"http://web.customer_relations_iss.net"</A>></CustomerRelations>
<Support Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" Country="US" Email=<A class=moz-txt-link-rfc2396E href="mailto:support@iss.net">"support@iss.net"</A> Fax="778-555-7755" Phone="777.555.7744" PostCode="30064" Weburl=<A class=moz-txt-link-rfc2396E href="http://web.suport_iss.net">"http://web.suport_iss.net"</A>></Support>
<Version>1.0</Version>
<OCN>163444</OCN>
<Source>ISS Atlanta</Source>
<Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
<Timestamp>2000-06-14 10:34:09</Timestamp>
</Contact>
==== end buffer:
= Status:
== Signatures ok: 0
== Signatures fail: 1
== SignedInfo Ref ok: 0
== SignedInfo Ref fail: 1
== Manifest Ref ok: 0
== Manifest Ref fail: 0
Error: operation failed
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2340C.E13F08A5--
------_=_NextPart_000_01C2340C.E13F08A5
Content-Type: application/octet-stream;
name="test_allkey_06.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="test_allkey_06.xml"
<!-- edited with XML Spy v4.3 U (http://www.xmlspy.com) by Dana Godfrey =
(Internet Security Systems) -->=0A=
<ISSKeys Source=3D"ISS Atlanta">=0A=
<!-- TestKey ISS keygen -->=0A=
<Contacts>=0A=
<Contact>=0A=
<Keys Address1=3D"2626 Somewhere Lane" Address2=3D"suite 200A" =
City=3D"Atlanta" Country=3D"US" Email=3D"keys@iss.net" =
Fax=3D"778-555-1212" Phone=3D"777.555.1212" PostCode=3D"30064" =
Weburl=3D"http://web.fubar.net"/>=0A=
<CustomerRelations Address1=3D"1313 knowwhere Lane" =
Address2=3D"suite 300A" City=3D"Atlanta" Country=3D"US" =
Email=3D"customer_relations@iss.net" Fax=3D"778-555-7799" =
Phone=3D"777.555.7788" PostCode=3D"30064" =
Weburl=3D"http://web.customer_relations_iss.net"/>=0A=
<Support Address1=3D"1234 Anvil Rd." Address2=3D"suite 440B" =
City=3D"Atlanta" Country=3D"US" Email=3D"support@iss.net" =
Fax=3D"778-555-7755" Phone=3D"777.555.7744" PostCode=3D"30064" =
Weburl=3D"http://web.suport_iss.net"/>=0A=
<Version>1.0</Version>=0A=
<OCN>163444</OCN>=0A=
<Source>ISS Atlanta</Source>=0A=
<Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>=0A=
<Timestamp>2000-06-14 10:34:09</Timestamp>=0A=
<sig:Signature xmlns:sig=3D"http://www.w3.org/2000/09/xmldsig#">=0A=
<sig:SignedInfo>=0A=
<sig:CanonicalizationMethod =
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>=0A=
<sig:SignatureMethod =
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>=0A=
<sig:Reference URI=3D"">=0A=
<sig:Transforms>=0A=
<sig:Transform =
Algorithm=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">=0A=
<sig:XPath>=0A=
not(ancestor-or-self::sig:Signature)=0A=
and (=0A=
(ancestor-or-self::node() =3D /ISSKeys/Contacts/Contact) =0A=
)=0A=
</sig:XPath>=0A=
</sig:Transform>=0A=
<sig:Transform =
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComment=
s"/>=0A=
</sig:Transforms>=0A=
<sig:DigestMethod =
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"/>=0A=
=
<sig:DigestValue>pj96s6n/wNTsaxKWMtqyTsWbTrU=3D</sig:DigestValue>=0A=
</sig:Reference>=0A=
</sig:SignedInfo>=0A=
=
<sig:SignatureValue>jDZBVuX7vtG1MgIQyii5+10NcG8nrE8ak0Vds12Kmrq3s7hiqUk6=
yP6ntt7izos/uDkakrrW0qwA=0A=
WrfRa0MfqIUdojyM1nzbqTmGX23BhCeU1BKvjFf75CEMikEhC+ZgY4lKN9BiIE5SV2DbirL8=
7TsZ=0A=
Kjta6tlwYgEMxGlCs4I=3D</sig:SignatureValue>=0A=
<sig:KeyInfo>=0A=
<sig:X509Data>=0A=
<sig:X509Certificate>=0A=
MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAoT=
DVdl=0A=
YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhcN=
MDIw=0A=
NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2Vi=
IERl=0A=
dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgkq=
hkiG=0A=
9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu=
9+mM=0A=
uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX=
6+JT=0A=
nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAOB=
gQBy=0A=
08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+C=
uyIK=0A=
wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0FS=
lg8c=0A=
GL2eqXYylPEeMvZ5aw=3D=3D=0A=
</sig:X509Certificate>=0A=
</sig:X509Data>=0A=
<sig:KeyValue>=0A=
<sig:RSAKeyValue>=0A=
<sig:Modulus>=0A=
y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0Q=
S7Re=0A=
D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc3=
8gfE=0A=
EkEJnS4iCzUC7WHsNgM=3D=0A=
</sig:Modulus>=0A=
<sig:Exponent>AQAB</sig:Exponent>=0A=
</sig:RSAKeyValue>=0A=
</sig:KeyValue>=0A=
</sig:KeyInfo>=0A=
</sig:Signature>=0A=
</Contact>=0A=
</Contacts>=0A=
<EndUsers>=0A=
<EndUser Address1=3D"666 Rockets way" Address2=3D"Apt. B" =
City=3D"Scienceville" CompanyName=3D"Spacely Sprockets" Country=3D"US" =
Email=3D"gjetson@sprokets.net" PostCode=3D"" State=3D"Disturbed" =
SubjectName=3D"George Jetson" Title=3D"Whipping Boy">=0A=
<Version>1.0</Version>=0A=
<OCN>163444</OCN>=0A=
<Source>ISS Atlanta</Source>=0A=
<Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE</Serial>=0A=
<Timestamp>2000-06-14 10:34:09</Timestamp>=0A=
</EndUser>=0A=
</EndUsers>=0A=
<LicensedModules>=0A=
<LicensedModule ContactInfo=3D"ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D" =
EndUserInfo=3D"CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity=3D"RO" =
LicenseExpiration=3D"2003-06-14" LicenseType=3D"evaluation" =
Limit=3D"2147483647" LimitOutOfMaintenance=3D"0" =
MaintenanceExpiration=3D"2003-06-14">=0A=
<Version>1.0</Version>=0A=
<OCN>163444</OCN>=0A=
<Source>ISS Atlanta</Source>=0A=
<Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial>=0A=
<Timestamp>2000-06-14 10:34:09</Timestamp>=0A=
</LicensedModule>=0A=
</LicensedModules>=0A=
</ISSKeys>=0A=
------_=_NextPart_000_01C2340C.E13F08A5
Content-Type: application/octet-stream;
name="test_allkey_06a.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="test_allkey_06a.xml"
<ISSKeys Source=3D"ISS Atlanta"><!-- TestKey ISS keygen -->
<Contacts><Contact><Keys Address1=3D"2626 Somewhere Lane" =
Address2=3D"suite 200A" City=3D"Atlanta" Country=3D"US" =
Email=3D"keys@iss.net" Fax=3D"778-555-1212" Phone=3D"777.555.1212" =
PostCode=3D"30064" Weburl=3D"http://web.fubar.net"/><CustomerRelations =
Address1=3D"1313 knowwhere Lane" Address2=3D"suite 300A" =
City=3D"Atlanta" Country=3D"US" Email=3D"customer_relations@iss.net" =
Fax=3D"778-555-7799" Phone=3D"777.555.7788" PostCode=3D"30064" =
Weburl=3D"http://web.customer_relations_iss.net"/><Support =
Address1=3D"1234 Anvil Rd." Address2=3D"suite 440B" City=3D"Atlanta" =
Country=3D"US" Email=3D"support@iss.net" Fax=3D"778-555-7755" =
Phone=3D"777.555.7744" PostCode=3D"30064" =
Weburl=3D"http://web.suport_iss.net"/><Version>1.0</Version><OCN>163444<=
/OCN><Source>ISS =
Atlanta</Source><Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial><Ti=
mestamp>2000-06-14 10:34:09</Timestamp><sig:Signature =
xmlns:sig=3D"http://www.w3.org/2000/09/xmldsig#">
<sig:SignedInfo>
<sig:CanonicalizationMethod =
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<sig:SignatureMethod =
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<sig:Reference URI=3D"">
<sig:Transforms>
<sig:Transform =
Algorithm=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">
<sig:XPath>
not(ancestor-or-self::sig:Signature)
and (
(ancestor-or-self::node() =3D /ISSKeys/Contacts/Contact)=20
)
</sig:XPath>
</sig:Transform>
<sig:Transform =
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComment=
s"/>
</sig:Transforms>
<sig:DigestMethod =
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"/>
<sig:DigestValue>pj96s6n/wNTsaxKWMtqyTsWbTrU=3D</sig:DigestValue>
</sig:Reference>
</sig:SignedInfo>
<sig:SignatureValue>jDZBVuX7vtG1MgIQyii5+10NcG8nrE8ak0Vds12Kmrq3s7hiqUk6=
yP6ntt7izos/uDkakrrW0qwA
WrfRa0MfqIUdojyM1nzbqTmGX23BhCeU1BKvjFf75CEMikEhC+ZgY4lKN9BiIE5SV2DbirL8=
7TsZ
Kjta6tlwYgEMxGlCs4I=3D</sig:SignatureValue>
<sig:KeyInfo>
<sig:X509Data>
<sig:X509Certificate>
MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAoT=
DVdl
YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhcN=
MDIw
NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2Vi=
IERl
dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgkq=
hkiG
9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu=
9+mM
uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX=
6+JT
nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAOB=
gQBy
08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+C=
uyIK
wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0FS=
lg8c
GL2eqXYylPEeMvZ5aw=3D=3D
</sig:X509Certificate>
</sig:X509Data>
<sig:KeyValue>
<sig:RSAKeyValue>
<sig:Modulus>
y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0Q=
S7Re
D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc3=
8gfE
EkEJnS4iCzUC7WHsNgM=3D
</sig:Modulus>
<sig:Exponent>AQAB</sig:Exponent>
</sig:RSAKeyValue>
</sig:KeyValue>
</sig:KeyInfo>
</sig:Signature></Contact></Contacts><EndUsers><EndUser Address1=3D"666 =
Rockets way" Address2=3D"Apt. B" City=3D"Scienceville" =
CompanyName=3D"Spacely Sprockets" Country=3D"US" =
Email=3D"gjetson@sprokets.net" PostCode=3D"" State=3D"Disturbed" =
SubjectName=3D"George Jetson" Title=3D"Whipping =
Boy"><Version>1.0</Version><OCN>163444</OCN><Source>ISS =
Atlanta</Source><Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE</Serial><Ti=
mestamp>2000-06-14 =
10:34:09</Timestamp></EndUser></EndUsers><LicensedModules><LicensedModul=
e ContactInfo=3D"ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D" =
EndUserInfo=3D"CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity=3D"RO" =
LicenseExpiration=3D"2003-06-14" LicenseType=3D"evaluation" =
Limit=3D"2147483647" LimitOutOfMaintenance=3D"0" =
MaintenanceExpiration=3D"2003-06-14"><Version>1.0</Version><OCN>163444</=
OCN><Source>ISS =
Atlanta</Source><Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial><Ti=
mestamp>2000-06-14 =
10:34:09</Timestamp></LicensedModule></LicensedModules></ISSKeys>
------_=_NextPart_000_01C2340C.E13F08A5--