W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2010

Re: Sorting of DOM input to c14n 2.0

From: Meiko Jensen <Meiko.Jensen@rub.de>
Date: 13 Apr 2010 20:14:32 +0200
Message-ID: <4BC4B488.9010602@rub.de>
To: "Pratik Datta" <pratik.datta@oracle.com>
Cc: "Scott Cantor" <cantor.2@osu.edu>, public-xmlsec@w3.org
Pratik Datta wrote:
> [...]
>  But I have seen in practice 99% of times one Reference signs one
> subtree only, it would be very strange for someone to have large
> number of subtrees. (One reason for signing multiple subtrees is to
> prevent wrapping attacks. E.g. in the SOAP case instead of using an id
> based reference to the soap:Body, it would be recommended to use an
> XPath to refer to the soap:Body, so that if someone maliciously
> inserts another soap:Body somewhere that would also be included in the
> selection thereby thwarting the attack. In this case too the number of
> subtrees to be signed is very small)
I pondered on reasons for having an XPath reference that ends up with
more than one subtree, and found different cases of potential interest:

a) referencing two or more subtrees that occurr only once, using the
XPath union operator (sth like "//A | //B"). In that case, you might be
better off with having two separate "Reference" elements within the
Signature, one for //A and one for //B.

b) referencing all elements in an array-style construct (e.g.
"/myArray/myParamToBeSigned"). In this case you might be better off with
signing the single root node of the array ("myArray") instead of all n
"myParamToBeSigned", as the only difference is made by the "myArray"
node itself. However, this does not work for complex array objects.
Consider a "myArray" of "myEntry" nodes, each having its own children,
among them a "myParamToBeSigned" element. Then, a reference to
"/myArray/myEntry/myParamToBeSigned" collects all n subtrees in a single
way, and can not be circumvented with signing "myArray", as this
includes all other params of the "myEntries" as well. In this case, we
definitely need some sorting for the XPath selection result set.
However, I'd wonder why an XPath evaluator should permute the document
order in such settings. => Do we need to explain this in the spec?

I'm not sure this really covers all cases though...
Received on Tuesday, 13 April 2010 18:14:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:13 UTC