[xmlsec] XMLSEC Reference URI question

Aleksey Sanin aleksey at aleksey.com
Wed Jul 24 18:22:28 PDT 2002

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 
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 
to boolean by a call to the boolean() function. From the same spec, 
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.


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.
>  Ferrell
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
>Sent: Wednesday, July 24, 2002 5:48 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: '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?
>Moultrie, Ferrell (ISSAtlanta) wrote:
>> 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
>>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 
>> <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!
>> Ferrell
>>Ferrell Moultrie (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
>>Internet Security Systems -- The Power to Protect 
>>xmlsec mailing list
>>xmlsec at 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
>==== 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 at 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 at 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 at 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
>			<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
>				<sig:KeyInfo>
>					<sig:X509Data>
>						<sig:X509Certificate>
>					</sig:X509Data>
>					<sig:KeyValue>
>						<sig:RSAKeyValue>
>							<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" 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
>			<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>
>==== 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/1193fb4a/attachment.htm

More information about the xmlsec mailing list