History: Question on C14N list of nodes instead of subtrees

A bit of archeology ... I've been corresponding with someone about 
performance and dependence on XPtr recently and brought up message [1]. I 
characterized (perhaps mistakenly) the issue as follows, but this sort of 
begs the question of why did we "burst/flatten" our nodelist in the first 
place? Was it so we could easily create subsets as a list of nodes (making 
the "node in subset test" easy?), so that we could easily remove comments?

---- Summary Characterization ----

1. When the signature is in the document being signed (enveloped) it has to 
except itself from the document: a signature can't contain itself (paradox).
2. One approach is to use XPath to throw out all the dsig element from the 
document and then sign it. BUT what if I'm an enveloped signature in a 
document that has *other* signatures that I want to sign. I need a way to 
say "only throw out the Signatutre element containing *me*" There's no easy 
way to do that so we invented the here() XPath function -- which is also in 
XPtr now.
3. The example is someone noting that when someone takes the 
enveloped-signature-in-a-document and embeds *that* document into another 
document, the here() expression and processing gets even heavier!
(4. Also note that in our use of XPath we have lists of XPath nodes 
(flattened/burst), not trees. So if we have an XPath element node *that's* 
all it is. "because XPointer typically indicates a subtree of an XML 
document's parse tree using just the element node at the root of the 
subtree, whereas Canonical XML treats a node-set as a set of nodes in which 
absence of descendant nodes results in absence of their representative text 
from the canonical form." 
5. The result is our expression gets really ugly (cause we need to always 
ask for (//. | //@* | //namespace::*) and the processing from the XPath is 
*very* slow: parsing the tree and doing counts. Merlin was indicating that 
in XPointer, the expression would look  prettier (since it points to a 
subtree, not just a flat node list) and I'm wondering about the performance 
of the XPointer here. Now that I think about it here() probably isn't 
something you'd want in a simple profile, but having it be there and have 
it be implemented by fast implementations could've been of use to us -- or 
could in a future version of xmldsig....

----- Old Email ----


Subject: Re: Problem: referring to a complete sub-tree using XPath
Date: Wed, 25 Apr 2001 09:48:53 +0100
From: merlin <merlin@baltimore.ie>
To: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
Cc: "XMLSigWG" <w3c-ietf-xmldsig@w3.org>

Hi Karl,

XPointer is the tool for this job, not XPath. It can do this
reference in a single path evaluation. The xmldsig standard
supports full same-document XPointer references; it is simply
an issue of implementing it ;}



>i use XPath in a reference to select a element of the same document and
> all its descendants, attributes,... - simply the subtree with the
> specific element as its root.
>i already have a XPath that works. however, its awfully slow, because its
>quite long for this simple task it perfoms.
>here a short example
><?xml version="1.0" encoding="UTF-8"?>
><aida:eDocument xmlns:aida="http://www.iaik.at/aida"
>xsi:schemaLocation="http://www.iaik.at/aida eDocument.xsd">
>  <aida:signedContent>
>    <personnel xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
>      <person contr="false" id="Big.Boss">
>        <name>
>          <family>Boss</family>
>          <given>Big</given>
>        </name>
>        <email>chief@foo.com</email>
>        <link subordinates="one.worker two.worker three.worker four.worker
>      </person>
>       ... (omitted some data)
>    </personnel>
>  </aida:signedContent>
>  <dsig:Signature Id="eDocumentSignature-1"
>    <dsig:SignedInfo>
>      <dsig:CanonicalizationMethod
>      <dsig:SignatureMethod
>      <dsig:Reference URI="">
>        <dsig:Transforms>
>          <dsig:Transform
>            <dsig:XPath xmlns:aida="http://www.iaik.at/aida"
>:eDocument[1]/child::aida:signedContent[1]//. |
>here()/ancestor::aida:eDocument[1]/child::aida:signedContent[1]//@* |
>:: *) | self::node()) =
> | here()/ancestor::aida:eDocument[1]/child::aida:signedContent[1]//@* |
> here()/ancestor::aida:eDocument[1]/child::aida:signedContent[1]//namespac
>e:: *))</dsig:XPath>
>          </dsig:Transform>
>        </dsig:Transforms>
>        <dsig:DigestMethod
>        <dsig:DigestValue>ssbkbDM6VCUTYyzXMK06RKcbFHQ=</dsig:DigestValue>
>      </dsig:Reference>
>    </dsig:SignedInfo>
>Po dMb1xUY1Y 
> 8iHpAcl8Z6xP3mMCK60ROtVCcDRS2v0ydULhJ+IZFjotIgwtGECy9lxZy4LDkeUJ
> RIvtzlDHBnp5jMb1+iLO1aTvkBzNLWbrAGo+rbqely4=</dsig:SignatureValue>
> <dsig:KeyInfo>
>      <dsig:X509Data>
>        <dsig:X509Certificate>MIIC .... (omitted some data)
>      </dsig:X509Data>
>    </dsig:KeyInfo>
>  </dsig:Signature>
>i need the here() functionality to ensure that the signature even
> verifies, if i embed the whole document into another xml document.
>the long XPath the you see in the example just selects the
><aida:signedContent> element with everything contained within this
> element. does anyone know a simpler XPath that does the same job? the
> performance of this is unacceptable: up to some minutes if i have a
> medium XML document in the signed content running without JIT. (i use
> Xerces 1.3.0 [with some patches])
>i did not want to use IDs, to be able to arbitrary include signed
> documents into other documents.
>  Karl Scheibelhofer

Received on Wednesday, 23 January 2002 15:28:25 UTC