Re: History: Question on C14N list of nodes instead of subtrees

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