RE: New proposed fix for here()

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
transforms
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
XPath
expression defines the canonicalization and enveloped signature
transforms,
but is not required to implement them.

I have not (and do not intend to) included XPath in my implementation.
However,
I would still like to be able to handle enveloped signatures (which my
implementation
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.

--Kevin

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


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