XMLDSIG proposal: enveloped signatures, xpath and here()

Hello,

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().

To abstract my proposal, it is to replace the suggested
XPath library function here(), which I do not think has
a meaningful definition, with an XPath variable
signature-id, which contains the Id attribute of
the dsig:Signature being created or verified. This
results in a cleaner definition of the enveloped
signature transform and simplifies general XPath
transformation.

It seems to me that in order to implement here(), one
must either present the signature document to the
transform in the form of the original structure of nodes
(here() being a concept from a node in the original
document) or else one must assume that there is an ID
attribute which can be used as a reference point to
implement the function on an octet stream.

If the former, then the definition of a transform
should be extended to allow the input and/or output
to be an XML structure and not just an octet stream.
This would essentially mandate that XPath and/or
enveloped signature transforms be the first in any
sequence of transforms applied to a reference, and is
how I currently implement the transform.

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>

This seems more logical and straightforward than the
here()-based construct and it has a precise meaning for
any document.

The downside would be that the enveloped signature
transform could only be applied to a signature with an
Id, however this seems like a small sacrifice.

I do not believe that this raises any security issues;
if anything, the more precise definition is a benefit.

I would welcome any comments,

Merlin Hughes
Baltimore Technologies

Received on Monday, 17 July 2000 17:44:44 UTC