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

RE: Enveloped signatures and XPath

From: Mark Bartel <mbartel@thistle.ca>
Date: Fri, 24 Mar 2000 15:25:01 -0500
Message-ID: <3C4B400C1E317E4799AAAF2317BDCED104626A@arafel.ealdwood.thistle.ca>
To: "'John Boyer '" <jboyer@PureEdge.com>, "'Petteri Stenius '" <Petteri.Stenius@remtec.fi>, "'IETF/W3C XML-DSig WG (E-mail) '" <w3c-ietf-xmldsig@w3.org>
I quite like the idea of an IDREF exclusion transformation.  I have some
problems with using XPath, myself.  The main problem being also the main
advantage of XPath:  an XPath is essentially a piece of embedded executable
code in the document.

So, I have a document from somewhere, with Mallory's signature on it.  My
software needs to verify the signature.  If that signature has an XPath in
it, my software not only needs to understand the document, but it must
either evaluate the output of the XPath expression (or check the end result
of the Transforms) and make sure it is appropriate (test it against some
kind of document definition?), or it must understand the XPath expression
itself, and "know" that the expression is doing the right things.  It would
be much simpler to verify that the exclusion was correct with an IDREF
exclusion transformation.  "Does the signature itself have the exclusion id,
yes or no?"

Basically, it seems to me that different issues are being lumped together
here:

* signing an element but excluding contained elements - XPath is currently
the only way to do this; I like the idea of having an IDREF exclusion
Transform

* signing a document definition (aka document closure) - one way of doing
this is via using an XPath expression in the signature that starts at the
root of the document and eliminates specific bits.  In this way it can
ensure that the unsigned bits of the document are only changed in certain
ways.  Essentially, the XPath is the document definition.  Another way of
doing this is simply putting a reference to some form of document definition
into the signature (ie. a reference to a DTD, Schema, form template, or
whatever).  XPath is of course more general and can handle arbitrary XML,
but I feel that the including a reference to a document definition (which
could be embedded) is more straightforward and adequate for many needs.  In
either case, the verifier has to determine whether they trust the document
definition, probably by comparing it to known XPaths in the XPath case or
trusted document definition in the "plain link" case.

The big difference between the XPath approach and the plain link case is
that the verifier is automatically verifying that the document matches the
"document definition" when they evaluate the XPath; they can't do anything
else.  In the plain link case, the verifier can choose not to test the
document against the document definition.

I would like to see an exclusion mechanism that does not involve XPath.  The
fact that the XPath transform can do anything is precisely the reason for
wanting a simpler transform that can't.

-Mark Bartel
JetForm

-----Original Message-----
From: John Boyer
To: Petteri Stenius; IETF/W3C XML-DSig WG (E-mail)
Sent: 3/23/2000 3:18 PM
Subject: RE: Enveloped signatures and XPath

Actually, no it isn't enough to excluded by IDREF and no we shouldn't
add
more transforms.

1) Exclusion by IDREF simply means that some element given by ID was
excluded at the time of signing and is now excluded.  It is difficult to
say
anything about what was the excluded element was at the time of signing.
It
would have to be excluded if and only if:

a) it's ID matched some value
b) it was in fact a SignatureValue
c) it did in fact have a certain ancestry

Otherwise, you run the risk of being able to produce documents that fool
the
system at the time of signing.  And its not really that I expect such
fooling around to occur often.  I am more concerned with the attempt to
repudiation transactions based on the argument that such fooling around
'could' occur.  This is how technology disservices the relying party.

2) There should not be a proliferation of transforms that implement
parts of
the XPath transform.  If you find the XPath transform useful, use it.
XPath
is sufficiently powerful to deal with any partial document needs you may
have, so there should not be a need for other means of obtaining parts
of
the document.

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
jboyer@PureEdge.com





-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Petteri Stenius
Sent: Thursday, March 23, 2000 11:54 AM
To: IETF/W3C XML-DSig WG (E-mail)
Cc: 'Martin J. Duerst'
Subject: RE: Enveloped signatures and XPath



Yes, excluding the Signature or SignatureValue element (without using
XPath)
is the main concern with enveloped signatures.

I believe it could benefit many if more transforms were added to the
spec, a
generic "exclusion by IDREF" algorithm would be enough to solve
enveloped
signatures.


Petteri


> -----Original Message-----
> From: Martin J. Duerst [mailto:duerst@w3.org]
> Sent: Thursday, March 23, 2000 5:11 AM
> To: Petteri Stenius; IETF/W3C XML-DSig WG (E-mail)
> Subject: Re: Enveloped signatures and XPath
>
>
> At 00/03/22 19:39 +0200, Petteri Stenius wrote:
>
>
> >The interop requirements doc reads:
> >
> >"Feature: Enveloped Signature MUST
> >         requires: XPath selector that drops SignatureValue"
> >
> >
> >I remember there was some talk about this at the FTF meeting
> in San Jose. It
> >was discussed that it could be possible to detect this
> particular XPath
> >expression without implementing the entire XPath support.
> >
> >Has anyone worked out a (standard?) XPath expression for
> excluding the
> >Signature or SignatureValue element?
>
> If that's the main concern, it may even be possible to define
> a transform that cuts out the SignatureValue element without
> using XPath at all.
>
>
> Regards,   Martin.
>
Received on Friday, 24 March 2000 15:25:24 GMT

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