Re: XPath expressions in digital signatures

Bruce Rich wrote:
> Sean,
> We talked earlier today about the discrepancies between the document 
> subset expressions that appear in the Interop document and those that 
> appear in the Signature files that Sun has generated.
> For example, the document subset expression for testcase 
> c14n11/xmlbase-prop-1 in 
> is
> (//. | //@* | //namespace::*) [ancestor-or-self::ietf:c14n11XmlBaseDoc1 
> and not(ancestor-or-self::ietf:e2)]
> But the XPath expression in the Signature in 
> is
> ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e2)
> For the benefit of the rest of the list, would you like to comment on 
> the disparity?


The expressions that are in the interop doc (for example, in section
3.2.1 [1] are applicable to the standalone c14n testcases. They are not
correct for the XPath Transforms that appear in XML Signatures. This is
explained in section 6.6.3 of the XML Signature rec [2], which I will
attempt to explain briefly:

The input to an XPath Transform is a node-set. In the case of the test
signatures, however, it is an octet stream because it is the result of
dereferencing the file: URI pointing to the input files. Section 6.6.3
states that the application must convert an octet stream to a node-set
and this is done by the following steps:

    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::*)

Therefore the (//. | //@* | //namespace::*) expression should not be
included in the XPath Transform. The expression in the XPath transform
should only be the filter expression that should be applied to each
node, which is the remaining part of the expression:
ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e2)

Putting this another way, it would not make sense to evaluate the full
document subset expression for each node in the input node-set, as the
expression is not a boolean expression.

I recommend we update the tests in section 3.2 with a note about this.


Received on Thursday, 13 September 2007 14:24:11 UTC