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

RE: New proposed fix for here()

From: John Boyer <jboyer@PureEdge.com>
Date: Tue, 15 Aug 2000 09:59:23 -0700
To: "Petteri Stenius" <Petteri.Stenius@done360.com>, "'merlin'" <merlin@baltimore.ie>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>
Message-ID: <BFEDKCINEPLBDLODCODKGEFOCEAA.jboyer@PureEdge.com>
Hi Petteri,


I like John's proposal of calculating the XPath expression identifying the
Signature element.

<jb>Thanks.</jb>

What I dislike about tweaking the URI syntax of the Reference element is
that we are only moving the XPath etc. expressions to an other location in
the syntax, not really proposing a new solution.

<jb>
I didn't like it either when I thought it through well enough to try writing
it up, which is why I sent the new proposal.

Unfortunately for both of us, Merlin makes the interesting point that my
newest proposal only works when the octet stream input to the enveloped
signature transform is indeed the whole document (no, Merlin, Larium had no
effect; you are right).  If I'm not mistaken, the XMLTransform idea has
similar problems.

Actually, the thing I don't understand is why we have an enveloped transform
at all.  Clearly, it is not a transform like the others, and we've tried
hack after hack to get it to work-- without success.  My original thoughts
on enveloped signatures is that they would be done by XPath transforms that
were specific to the document.

The only thing I can figure out is that XPath is recommended, not required.
But is that such a big deal.  We recommend XPath because you can do
enveloped signatures without it, but we don't require it because many can
get by without enveloped signatures.  If you want enveloped signatures, then
implement the XPath transform and be done with it.  Then, you can write the
XPath expression that omits the Signature by taking into account what
Transforms you've put beforehand.

Still, I'll keep thinking about this and bring it up on the teleconference.
</jb>

My "hack" when implementing the enveloped-signature and to work around ID
conflicts has been to generate a random string to use for a temporary
identifier attribute of the Signature element.

<jb>
Not a bad idea at all since the signature gets omitted, but does seem to
leave a small hole in that the enveloped signature transform's input may be
the output of another transform that just happens to have an element other
than the Signature element that has the same id value.  This would be also
be legal once the DTD is stripped out.  As well, it could even occur if you
switched from a random string to a string guaranteed to be unique from all
id's in the original document containing the signature.

And if you tried to do it to the transform input, then you'd be able to
uniquely identify the Signature in that input, so you'd have to have the
problem solved in order to solve the problem.

In a nutshell, if the input is what we expect, then it works, but if the
transform input is not solely derived from the input document, then there
could be problems.

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/>
</jb>

Petteri
Received on Tuesday, 15 August 2000 12:59:34 GMT

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