[xmlsec] XMLSEC Reference URI question

Wed Jul 24 18:48:12 PDT 2002

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 at aleksey.com] 
Sent: Wednesday, July 24, 2002 9:22 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: 'xmlsec at 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 at aleksey.com <mailto:aleksey at aleksey.com>
] 

Sent: Wednesday, July 24, 2002 5:48 PM

To: Moultrie, Ferrell (ISSAtlanta)

Cc: 'xmlsec at aleksey.com <mailto:xmlsec at 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 at iss.net <mailto:ferrell at 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 at aleksey.com <mailto:xmlsec at 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 at iss.net" <mailto:keys at 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 at iss.net" <mailto:customer_relations at 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 at iss.net"
<mailto:support at 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 at sprokets.net" <mailto:gjetson at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20020724/c10e440e/attachment.htm