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

Hi Kevin,

Relocatable signatures also have the problem that they break of the
namespace context changes, however, Merlin seems to be referring to the
problem that if you identify signatures by an id attribute, then you cannot
relocate many of them into the same document (e.g. to form a list of search
results, each of which is signed).

However, if I understand what Merlin is saying correctly (also below), he is
using an Xpointer in the Reference to indicate what to sign.  Let's run with
that basic idea for a moment.

Since XPointer is based on XPath, we could create an XPointer in the
Reference whose expression argument is equal to the XPath we current have in
the enveloped signature specification (except that it is currently in an
XPath transform).

In total, we could

1) drop here() from the XPath transform
2) rewrite the enveloped signature specification to use a Reference with an
Xpointer URI that is equal to the current XPath for enveloped signature.
3) Convert the resulting location-set to a node-set (throw error if there
are any point, range or other non-node parts of the location-set)
4) C14N the resulting XPath node-set.

The second point can be done by using the here() function present in
XPointer, basically using the same XPath expression we currently have in the
specification for enveloped signature.

The third point is an interesting new twist, but I believe it is a problem
with the current dsig spec whether or not we use XPointer to solve the
enveloped signature problem.  We have assumed that people can use a URI that
includes at least a barename Xpointer.  But the result of a barename
XPointer is a *location-set*, not an octet stream.  To fix this, I believe
we have assumed that the canonicalized result of the barename xpointer would
be passed to the transforms (at least I have).  But c14n operates on a
node-set, not a location-set.  However, certainly in the case of barename
xpointer, the location-set is a node-set (there are no non-nodes), so
canonicalizing it presents no real problems.

Finally, I should point out that this idea is pretty similar to the earlier
concept of creating a special XMLTransform first, or somehow treating the
first transform differently, except that it keeps the data flow model for
transforms clean by making the reference URI be that special first
transform.

Would the current primary stakeholders (Merlin, Kevin, Kent, Joseph and Don)
agree with this approach?  If so, I can make the required changes to the
XPath and Enveloped signature sections before the FTF.

Thanks,
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 3:12 PM
To: merlin
Cc: John Boyer; TAMURA Kent; w3c-ietf-xmldsig@w3.org
Subject: Re: XMLDSIG proposal: enveloped signatures, xpath and here()



Isn't the problem of relocatable signatures more to do with the
fact that the Signature element (and its children) rely on parent
namespace declarations, so it can not be moved to another document
with a different namespace hierarchy?

--Kevin

>
> 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 Wednesday, 26 July 2000 14:29:19 UTC