W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

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

From: merlin <merlin@baltimore.ie>
Date: Mon, 24 Jul 2000 23:02:56 +0100
Message-Id: <200007242202.XAA02230@bobcat.baltimore.ie>
To: "John Boyer" <jboyer@PureEdge.com>
Cc: "Kevin Regan" <kevinr@valicert.com>, "TAMURA Kent" <kent@trl.ibm.co.jp>, w3c-ietf-xmldsig@w3.org
r/jboyer@PureEdge.com/2000.07.24/13:36:51
>The second issue is a very serious and difficult problem surrounding the
>feasibility of actually setting up a return value for here().

Thank you for your summary of this problem. Clearly a simple variable
does not provide all the flexibility of the here() function.

From an implementational standpoint, a functional but unclean
solution would be to document that the input to the first
transform may be the XML tree containing the signature (for
a local reference) and that a here()-based transform may only
be used to immediately transform such a reference. This reduces
the task to a manageable size. I believe that others, and I,
have successfully implemented something of this nature.
However, it is unclean.

Introduction of a new element would render a cleaner solution,
however I'm not sure that this is necessary.

  <!ELEMENT Reference ( XMLTransform?, Transform* .. )>

In this case, enveloped signature and here()-based xpath
transforms would be moved to an XMLTransform element, and
Transform would be unchanged.

I still think that we can get away without this change. However,
I have clearly given this less thought than the collective, so
I welcome criticism.

In terms of the security of variables, my expression of enveloped
signatures involved dsig:Signature[@Id=$xmldsig-signature-id]; I
deliberately assumed that identifiers were not resolvable. So this
can only be used by an attacker to eliminate content enclosed
within Signature elements. A security risk but, I believe, a lesser
one; it involves a significant and obvious structure.

Further, the risk is only present if a verification application
makes incorrect assumptions about the transform, a risk which
exists with any transform. The definition of the transform is
that _all_ such Signature elements and their subtrees are removed;
to assume otherwise would be incorrect. Clarification in the
document would be required.

The problem of relocatable signatures is an interesting one,
however it can be solved in two ways. One is for the signatures
to use null references; the referenced data is implicitly the
associated datum, known to the appication. Alternatively, use an 
XPointer in the reference to identify the relevant data (I believe
that is the correct technology) and then an XPath, if necessary,
to select from it:

  <Reference URI='#xpointer(../../previous-sibling)'>

Technologically, all verifiers which support XPath transforms
contain the necessary tools for XPointer resolution. So adding
a need for this is a minimal burden.

Merlin
Received on Monday, 24 July 2000 18:03:27 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:10 GMT