[xmlsec] XPointer problem

[Matthias Jung]

This is a multi-part message in MIME format.
--------------020506060109010006090800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Aleksey,

thanks a lot for for fixing this problem so fast. I agree that handling such
expressions now is a good solution and that using XPath expressions is
better for interoperability reasons. That's exactly the reason why I am
testing our software even using XPointers :-)

Let's continue this interop discussion when there are more DSig implementations 
capable of handling xpointer expressions. Xss4j, the only one I had a look at, does
not support this feature.

Now that this problem is fixed, I found another (last) problem within my test 
suite. Please have a look at the digest values of the two references in the
attached signature file, which should not be equal as the references point to different
elements. It seems that xpointer expressions containing child sequences are
handled wrong, or something with my expressions is faulty.

I have checked this behaviour using libxml's testXPath executable. The result is:

  testXPath.exe --input sig_xpointer_absolute_path_templ.xml --xptr /1/2
  Object is a Node Set :
  Set contains 1 nodes:
  1  ELEMENT soap-env:Body

(looks good)

  testXPath.exe --input sig_xpointer_absolute_path_templ.xml --xptr xpointer(/1/2)
  Object is a Node Set :
  Set contains 1 nodes:
  1   /

(looks like an empty document)

I have no clue if this is a problem is caused by me, by xmlsec, or libxml.

Thanks a lot for any suggestions,

Matthias



Aleksey Sanin wrote:

> Matthias,
>
> The fix for this problem is trivial (see attached file). I've checked 
> it in
> both XMLSEC_0_0_X_BRANCH and the tip. However, it'll require
> a minor change on your side as well. You need to remove one "xpointer"
> as follows:
>
> <Reference
> URI="#xmlns(soap-env=http://schemas.xmlsoap.org/soap/envelope/)xpointer(/soap-env:Envelope/soap-env:Body)">
>
> I am absolutelly not sure that this will be interoperable with other 
> XML DSig
> toolkits but it seems logical to me. For example, compare the reference
> URI above with this one:
>
> <Reference URI="#xpointer(/Envelope/Body)">
>
> Another way to achieve the same goal is to use empty URI ("") and an
> XPath transform that will look similar to the XPointer expression you are
> using now. I doubt that there will be any visible performance penalty.
> And IMHO, XPath transform is better solution because of possible interop
> issues I mentioned above.
>
>
> Thanks for reporting this problem! And you are not bothering me at all :)
>
> Aleksey
>

--------------020506060109010006090800
Content-Type: text/xml;
 name="sig_xpointer_child_sequence_xmlsec.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sig_xpointer_child_sequence_xmlsec.xml"

<?xml version="1.0"?>
<soap-env:Envelope xmlns="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
	<soap-env:Header>
		<wsse:Security>
			<sci:SamlToken xmlns:sci="http://www.xtradyne.com/sci"/>
			<ds:Signature>
				<ds:SignedInfo>
					<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
					<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
					<ds:Reference URI="#xpointer(/1/2)">
						<ds:Transforms>
							<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
						</ds:Transforms>
						<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
						<ds:DigestValue>2jmj7l5rSw0yVb/vlWAYkK/YBwk=</ds:DigestValue>
					</ds:Reference>
					<ds:Reference URI="#xpointer(/1/1/1/1)">
						<ds:Transforms>
							<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
						</ds:Transforms>
						<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
						<ds:DigestValue>2jmj7l5rSw0yVb/vlWAYkK/YBwk=</ds:DigestValue>
					</ds:Reference>
				</ds:SignedInfo>
				<ds:SignatureValue>Q8KepWaxn3G5SMi/kAUqB5mKCXCTgIKkNzbbUF0zUa7XG0QGBQBtmT/UgvFL7gLiGWfe6ITYzfqT/ZzEkdEZa+6IoT/l3hSdlvtxAhNtpCXhk7/Nj4VYmW7d5AZkQxvE5AtVfAnRBbTJKCjxjqt+gtL3xJzYxD92+dkB/Mz7Vn8=</ds:SignatureValue>
				<ds:KeyInfo>
					<ds:X509Data>
<ds:X509Certificate xmlns="http://www.w3.org/2000/09/xmldsig#">MIICWzCCAcSgAwIBAgIBADANBgkqhkiG9w0BAQQFADAuMQswCQYDVQQGEwJY
RDESMBAGA1UEChMJTXlDb21wYW55MQswCQYDVQQDEwJDQTAeFw0wMjA3MjYw
OTQ2MTFaFw0wNDA3MjUwOTQ2MTFaMC4xCzAJBgNVBAYTAlhEMRIwEAYDVQQK
EwlNeUNvbXBhbnkxCzAJBgNVBAMTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC+y2cVD1DGeybtrwt9zwL4C2gHdqDBKM8OlBADlzFWyl88JWqi
EHZ9dNDl8yFyuW0yjgkhmab8NA+y3aX97BM57M+0WoBbukXcZnDulqvIMNEX
I7uDwnLrq5vyDEInKR4IRAfKl6/dybYozUgNrMJIBxUaVbjTr23/7bV1nU9T
pQIDAQABo4GIMIGFMB0GA1UdDgQWBBRUyK6EVzAl3Sl/lpRZ2I4lN9y2hDBW
BgNVHSMETzBNgBRUyK6EVzAl3Sl/lpRZ2I4lN9y2hKEypDAwLjELMAkGA1UE
BhMCWEQxEjAQBgNVBAoTCU15Q29tcGFueTELMAkGA1UEAxMCQ0GCAQAwDAYD
VR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQAOImAnIhZuVCfTSx1SrASz
vJQdMW+7xIw0oXiSEveigzvoe8oskleWbTRQW1NkeS8Cq6Y93deXflRpDuwQ
Ij2jH2upyvYm85crZPDgaiOlzBP+A3f1yK/WECihAnTwj3TNl1V/WoYQbj/O
hou7/sBeHHb91B1sjkx6AIEDv8DeQQ==</ds:X509Certificate>
</ds:X509Data>
				</ds:KeyInfo>		
			</ds:Signature>
		</wsse:Security>			
	</soap-env:Header>
	<soap-env:Body>	
	</soap-env:Body>
</soap-env:Envelope>

--------------020506060109010006090800--