RE: XMLDSIG proposal: enveloped signatures, xpath and here()

Hi all,

So far, I've seen two issues for the here() function.

The first was raised by Kent, who asked what to return for he<!-- -->re().
Good one!  The XPointer folks are going to need to solve this too, but I
think the answer is to return the text node containing the 'h' of here().

The second issue is a very serious and difficult problem surrounding the
feasibility of actually setting up a return value for here().

For those who may just be joining this thread, and because noone has yet
said what the problem actually is, I'm going to assume that the problem is
as follows (please correct if there is some other problem in addition to
this one):

The overarching design we have is that an octet stream is passed from
transform to transform indicating the data on which the transform must act.
It is this data for which the XPath transform creates a node-set.  In order
to set up a return value for here(), we require a node-set representative of
the current document containing the XPath expression.  These are two
different node-sets.

The here() function defined in XPointer (and defined by the Xpath transform)
is actually only useful when the current document's node-set and the XPath
evaluation node-set are one and the same.  The $signature-id variable is a
way to make an indication of a node that will be created when the XPath
transform input is converted from an octet stream into a node-set.

I do not see a clear way to resolve this problem at this time.  However,
there is also a problem with the $signature-id proposal that lead us to do
something like here() in the first place.

The problem is that $signature-id is being set equal to the value of an
attribute that happens to be called 'id'.  Any number of elements could have
such an attribute, and all could use the same 'id' value as the signature in
order to have themselves omitted from the digest value computed over the
result of the XPath expression being evaluated.  Furthermore, having these
equivalent 'id' values is permissible under non-validating XML parsers and
also under validating parsers if the 'id' attribute is not actually of type
ID (and we have no way of knowing this).  Hence, security risk.

As well, enveloped signatures were not the only use for here().  At the
Victoria FTF, Mariano Consens championed the here() function because it
allowed the signature of elements whose positions relative to the Signature
element were predefined and maintained under movement of those signatures to
other documents.  For example, suppose one wanted to create a signed e-check
in which the check element was identified by id="C" and the signature
element immediately followed the check element.  Now suppose one wants to
move 10 such signed checks into a compound document.  The identical id
settings would not pass a validating XML parser, so the id="C" cannot
actually be used.  To solve the problem, here() would be used to help
identify "the sibling element immediately preceding 'this' signature".

The idea behind here() is that it is supposed to uniquely identify the
Signature element of the signature currently being created.  Perhaps we can
give more thought to how to fix it since the $signature-id and all related
ideas have a fairly serious problem and given that there are uses beyond
enveloped signatures.

Finally, note that I would've preferred a more generic mechanism for the
XPath transform in which we allowed the Signature element creator to set up
any desired variable context rather than having the one specific, implicit
variable named $signature-id.  However, I am loathe to ask for this change
at this late stage unless it solved a specific problem, and as we can see
from $signature-id, variables can easily cause more problems than they
solve.

John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Kevin Regan
Sent: Monday, July 24, 2000 10:36 AM
To: TAMURA Kent
Cc: w3c-ietf-xmldsig@w3.org; Merlin Hughes
Subject: Re: XMLDSIG proposal: enveloped signatures, xpath and here()



Isn't the Id attribute for Signature optional?  In this
case, I don't think that it can be used as a general way
of identifying the Signature node from within the spec (although
applications may set an Id for the Signature node and use
it in other ways).

--Kevin


On Sun, 23 Jul 2000, TAMURA Kent wrote:

>
> In message "XMLDSIG proposal: enveloped signatures, xpath and here()"
>     on 00/07/17, Merlin Hughes <merlin@baltimore.ie> writes:
> > After implementing the transforms from WD-xmldsig-core-20000711
> > I have been left with some conceptual troubles over the
> > specification of the enveloped signature and XPath transforms;
> > and, in particular, here().
>
> These troubles are the same as I wrote in the following mail:
> 	> Date: Mon, 3 Jul 2000 14:16:06 +0900
> 	> From: TAMURA Kent <kent@trl.ibm.co.jp>
> 	> To: w3c-ietf-xmldsig@w3.org
> 	> Subject: Transform I/O is a sequence of octets
>
>
> In message "XMLDSIG proposal: enveloped signatures, xpath and here()"
>     on 00/07/17, Merlin Hughes <merlin@baltimore.ie> writes:
> > If the latter, then why not eliminate the here()
> > function and replace it with an XPath variable that
> > corresponds to the Id of the Signature.
> >
> > The resulting XPath definition of the enveloped signature
> > transform would be:
> >
> > <XPath xmlns:dsig="&dsig;">
> >   (//. | //@* | //namespace::*)
> >
> [not(ancestor-or-self::dsig:Signature[attribute::Id=$signature-id])]
> > </XPath>
>
> I prefer this proposal.  This is simpler and easier to implement
> than here().
>
> --
> TAMURA Kent @ Tokyo Research Laboratory, IBM
>

Received on Monday, 24 July 2000 16:37:09 UTC