- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 23 Jan 2002 18:57:46 -0500
- To: "John Boyer" <JBoyer@PureEdge.com>, "merlin" <merlin@baltimore.ie>
- Cc: <w3c-ietf-xmldsig@w3.org>
On Wednesday 23 January 2002 18:15, John Boyer wrote: > Before I answer, I would point out that XPointer is based on XPath, and > XPath has the same capability w.r.t. its possible use for indicating Right. > interpretation of the word "set". Indeed, it is even possible to do > this with XPointer (location-set), and I advocated this at one point, > but the group decided against using XPointer only because we wanted a > shorter time to REC (though this was over a year ago!). To be fair c14n did go to REC and while xmldsig didn't because of bi-institutional process lag it garnered at least 12 implementations in that time! XPtr still isn't a REC and I think has ~1 complete implementation. (I was looking into XPtr *because* there's still some contention about its status and advancement so I think we made the right decision!) > Aside from legality, the individual node interpretation of XPath results > was necessary in order to implement the notion of signature filters, > which specify the portion of a document to be signed and/or the portion > to be omitted, the latter being inherently more secure. I did an RSA > 2000 presentation on this issue and numerous emails exist in the archive > about 'document closure'. The basic idea is that if you specify the > portions of a document covered by a signature, then it is easy to add to > the document without breaking the signature. It becomes very difficult > to assess whether the additions have an implicit impact on the signed > material. By comparison, if a signature says "sign everything except X, > Y, Z" then additions other than X, Y and/or Z will break the signature. > It is comparatively easier to establish the security of a message if all > you have to prove is that X, Y and Z cannot cause a security problem > within the application domain (or that any such possibility is covered > by post-core-validation application-specific steps). > > In essence, we made easy things a little harder to say so that we could > make hard things possible to say. I understand this aspect but I'm wondering (in a muddled way) why "the result of the XPath expression id("E") is a node-set containing only the node corresponding to the element with an ID attribute value of "E". Could one do the same with a nodelist as a list of subtrees (if necessary) where each subtree corresponded to an "orphan node" subtree resulting from the expression, otherwise the subtree is the subtree resulting from the filtering and there's parent-child contiguity? (I'm not saying I like this or that's it better just clearing some cobwebs from the attic now that I'm thinking about XPtr not being widely implemented and (independently) XPath2.0 (which is base on Infoset...)) >Finally, as to the speed issue that the originator is experiencing, I'd >say he is suffering from a non-optimized implementation. The reason is >that an O(n) traversal of the nodes of a parse tree is sufficient for >including all such nodes in a node-set. Since all members of the >node-set will be rendered in a serialization, the cost is O(n). Thus, >the cost of putting all nodes in a node-set should (or can at least) be >commensurate with serialization. If it is taking progressively longer >to calculate the node-set as the XML document grows, then the XPath >implementation needs to be optimized. Alternately, we only require >behavior equivalent to the evaluation of the (//. | //@* | >//namespace::*) expression.
Received on Wednesday, 23 January 2002 18:58:03 UTC