W3C home > Mailing lists > Public > public-xmlsec@w3.org > February 2011

FW: XPath 2.0 profile for XML Dsig 2.0

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 28 Feb 2011 15:41:14 -0800 (PST)
Message-ID: <85cc5585-2c33-4781-9e17-a9ce1085f9b6@default>
To: public-xmlsec@w3.org


-----Original Message-----
From: Pratik Datta 
Sent: Monday, February 28, 2011 2:14 PM
To: public-xmlsec@w3.org
Subject: XPath 2.0 profile for XML Dsig 2.0

Currently we have only proposed an XPath 1.0 profile for XML Dsig 2.0

I am also considering an XPath 2.0 profile for XML Dsig 2.0.  For this we can either come up with an XPath 2.0 subset from scratch, or just take the 1.0 subset and tweak it.  I am trying the former approach.


XPath 2.0 has an "XPath 1.0 compatibility mode". I have been told that we should not use this, because then it is no better that only supporting XPath 1.0. We need to support XPath 2.0 in its regular mode.


XPath 2.0 is very different from XPath 1.0,  however for very simple expressions like /book/chapter they return the same thing. Here are the major differences:

* Diff 1:  XPath 2.0 doesn't have nodesets, but has sequences.  Unlike nodesets, sequences allow duplicates, and are also ordered.  However this difference is not significant in our context, because the C14N 2.0 algorithm takes the elements returned by XPath, considers them as subtrees, orders them document order and removes duplicates.

Sequences can contain not only nodes , but also literals. The XPath 2.0 subset that we will propose will only allow nodes.


* Diff 2: XPath 2.0 has strong datatyping,  so for example in  /book[page="2.0"]. the  equality comparison will be done in numeric mode, in which "2.0" is same as "2". This is not so in XPath 1.0. 

This is a problem for us, because C14N 2.0 cannot assume that there is always a schema present. In many scenarios , especially in Web service security, the security code executes before the application code, and the security code cannot assume that the application schemas are available.  However in some scenarios the schemas will be present.  This can lead to a different set of nodes being selected between signing and verification - we can possibly solve this problem by mandating that all XPath 2.0 executed in the context of signature processing must be done without schemas.


* Diff 3: XPath 2.0 also allows for loops and other constructs
 e.g. 

for $i in (1,10) return $i
  
for loops can easily be exploited in Denial of Service attacks. So I don't see any reason for even considering this in XPath 2.0 subset for XML Dsig 2.0


* Diff 4: Xpath 2.0 has many more functions and operators.



We can discuss some of these things in tomorrow's call, and after that I can work out a strawman of the XPath 2.0 subset.

Pratik
Received on Monday, 28 February 2011 23:43:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 February 2011 23:43:03 GMT