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

RE: New proposed fix for here()

From: Kevin Regan <kevinr@valicert.com>
Date: Tue, 15 Aug 2000 14:15:52 -0700
Message-ID: <27FF4FAEA8CDD211B97E00902745CBE201AB43F6@seine.valicert.com>
To: John Boyer <jboyer@PureEdge.com>, Petteri Stenius <Petteri.Stenius@done360.com>, "'merlin'" <merlin@baltimore.ie>
Cc: XML <w3c-ietf-xmldsig@w3.org>

I did like the fact that XPath was not required in order to implement
canonicalization or the enveloped signature transform.  If I remember
correctly, XPath was introduced for canonicalization and the enveloped
signature transform as a convenient way of expressing those transforms.
It seems regrettable that a syntax introduced to express those
is now "taking over" the transforms and becoming "required" in the sense
that if XPath is not implemented, then enveloped signatures will not
be possible (this would seem to suggest that XPath was not an adequate
means of describing the enveloped signature transform).

I would suggest that the current situation remain as is -- that the
expression defines the canonicalization and enveloped signature
but is not required to implement them.

I have not (and do not intend to) included XPath in my implementation.
I would still like to be able to handle enveloped signatures (which my
currently does by simply ignoring the signature node when canonicalizing
the document
subtree being referenced).

Any invasion of XPath syntax into the URI (or anywhere else) seems like
an ugly
compromise to me in order to facilitate the use of a syntax that was
simply meant
as an aid to expressing already-existent transforms.


-----Original Message-----
From: John Boyer [mailto:jboyer@PureEdge.com]
Sent: Tuesday, August 15, 2000 9:59 AM
To: Petteri Stenius; 'merlin'
Subject: RE: New proposed fix for here()

Hi Petteri,

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


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
the syntax, not really proposing a new solution.

I didn't like it either when I thought it through well enough to try
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
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
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
on enveloped signatures is that they would be done by XPath transforms
were specific to the document.

The only thing I can figure out is that XPath is recommended, not
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
get by without enveloped signatures.  If you want enveloped signatures,
implement the XPath transform and be done with it.  Then, you can write
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

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

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
the output of another transform that just happens to have an element
than the Signature element that has the same id value.  This would be
be legal once the DTD is stripped out.  As well, it could even occur if
switched from a random string to a string guaranteed to be unique from
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
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/>


Received on Tuesday, 15 August 2000 17:25:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC