- From: Dournaee, Blake <bdournaee@rsasecurity.com>
- Date: Tue, 7 Aug 2001 11:01:13 -0700
- To: "'Hans Granqvist'" <hansg@verisign.com>
- Cc: w3c-ietf-xmldsig@w3.org, "'reagle@w3.org'" <reagle@w3.org>
Hans, I am glad to see that someone else is concerned about this issue. As for the tool, it is currently internal as it uses RSA's XML Signature implementation, but as soon as I can get an open-source versions of everything, I can post it somewhere useful. Additionally, XPath tutorials that you mention (such as the one at www.zvon.org) actually *add* to the confusion instead of helping things (for XML Signatures anyhow). The expressions that you use for selecting an individual element work differently because XML Signatures calculate a boolean value for each node in the node set. This has been a source of confusion for many developers. Kind Regards, Blake Dournaee Toolkit Applications Engineer RSA Security "The only thing I know is that I know nothing" - Socrates -----Original Message----- From: Hans Granqvist [mailto:hansg@verisign.com] Sent: Tuesday, August 07, 2001 8:42 AM To: Dournaee, Blake Cc: w3c-ietf-xmldsig@w3.org; 'reagle@w3.org' Subject: Re: XPath Expression "Dournaee, Blake" wrote: > > ... > The reason why I asked was because I am focusing on the usability side > of our XML Dsig toolkit - our customers (developers) must be able to > understand XPath well-enough to be able to make useful, > *well-understood*, transformations for the power of XPath to be fully > realized. This is a very good point. When developing the Verisign DSIG toolkit that is part of XKMS [1], we found that the complexity of XPath is a factor that may hinder usage of such an API. > One problem right now is that it is difficult, if not impossible, to > see what you have actually signed if an XPath expression is employed. > That is, right now, you can "set" an expression and then make a > signature - but if your expression is wrong or improper, there is no > feedback in the final <Signature> structure that gives you a hint that > you goofed. The problem gets compounded further if this signature is > sent off and it verifies improperly. This sends developers on a huge > bug-hunt for the problem. Oh yes, been there, done that. ;) This problem is aggravated if the XPath expressions used are relative to a context node, e.g., containing "..", the implementation needs to be aware of what is legal and not. Many users also tend to want to stuff "here()" into a reference XPath (not XPath transform) where it is not defined. On the receiving end, during validation, the problem lies in knowing that the signature reference you process is indeed over what you think it is. With the complexity of XPath, it therefore seems a must that the schema or business process in use between parties should stipulate the exact expected XPath expression so that no ambiguity exists what is signed. Our toolkit implements an "isSigned(XPath)" function that returns true if the XPath expression is a subset what is signed. It seems somewhat useful. > ... > To alleviate the confusion in this area, I am working on a sample > application that takes an arbitrary input XML file and an XPath > expression, and then performs (and then canonicalizes) the output and > spits it back out. This type of mechanism allows customers to "see" > what they are actually signing after an XPath expression occurs. That tool sounds cool. Are you planning to make it available? I know that zvon.org [2] has an online tool that lets you shoot XPaths at a doc and see the result in color-coded glory. > ... > Joseph: What is the possibility of drafting a W3C Note that contains a > set of "cooked" XPath expressions for performing common tasks? I am > guessing this would be a godsend to developers who are struggling with > this issue. And, to continue the reasoning above, how can these pre-cooked expressions be pre-defined inside a schema? I could think of immediate uses, such as, in XKMS, defining, in XPath expression, what the signature over requests and responses *must* be. Thanks, Hans Granqvist, Verisign [1] http://www.xmltrustcenter.org/xmlsig/developer/index.htm (Note, this is a proposed API that will be part of the next XKMS release-- not the one that is currently downloadable.) [2] http://www.zvon.org/cgi-bin/xlab/bin/index.py (seems down at the moment. See http://www.zvon.org/xxl/XPathTutorial/General/examples.html for examples made with the tool.)
Received on Thursday, 9 August 2001 08:42:30 UTC