- From: Meiko Jensen <Meiko.Jensen@rub.de>
- Date: 13 Apr 2010 20:14:32 +0200
- 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