[xmlsec] XMLSEC Reference URI question
Aleksey Sanin
aleksey@aleksey.com
Wed, 24 Jul 2002 18:22:28 -0700
--------------070809050901050204090304
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
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) 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) 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)
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]
>Sent: Wednesday, July 24, 2002 5:48 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: '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">
>> <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)
>>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
>>
>>Internet Security Systems -- The Power to Protect
>>=====================================
>>_______________________________________________
>>xmlsec mailing list
>>xmlsec@aleksey.com 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
>== 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
>==== 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" Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" Weburl="http://web.fubar.net"></Keys>
> <CustomerRelations Address1="1313 k nowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email="customer_relations@iss.net" Fax="778-555-7799" Phone="77 7.555.7788" PostCode="30064" Weburl="http://web.customer_relations_iss.net"></CustomerRelations>
> <Support Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" Country="US" Email="support@iss.net" Fax="778-555-7755" Phone="777.555.7744" PostCode="3 0064" Weburl="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#">
> <sig:SignedInfo>
> <sig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></sig:CanonicalizationMethod>
> <sig:SignatureMethod Algorithm="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">
> <sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
> </sig:Transform>
> <sig:Transform Algorithm="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"></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="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
>
>
--------------070809050901050204090304
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>
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 type="cite"
cite="mid121184A7DB1F9143BB5E3FACCB54875703FAC4@atlmaiexcp02.iss.local">
<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>
</body>
</html>
--------------070809050901050204090304--