RE: New proposed fix for here()

Hi Kevin,

Actually, XPath was not introduced to do canonicalization and enveloped
signature.

XPath was introduced over a year ago to filter documents.  In order to
finish XPath, we had to serialize a node-set.

When XML Core WG dropped C14N, we had to pick it up because we have a
requirement (outside of XPath filtering) to create a digestible octet
stream.  The XPath serialization was the easiest way to accomplish our goal
while giving a firm footing to the notion of serializing document subsets.

The enveloped signature transform was added relatively recently at the
request of some WG members (at the Victoria Face to Face) because the WG
wanted a transform that could be REQUIRED.  Many felt that since we could
already deal with element omission on a document by document basis using
document-specific XPath transforms, then perhaps we could define a standard
XPath expression as an easy way of specifying enveloped signature.  This
turns out not to be true, but to reiterate, this was not the motivation for
adding XPath transforms.

Finally, the problem is not with XPath.  The problem is with our transform
processing model.  You said that your implementation ignores the Signature
node automatically.  This is the "hack" that everyone is talking about
because you are violating the transform processing model if your
implementation actually works.

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: Kevin Regan [mailto:kevinr@valicert.com]
Sent: Tuesday, August 15, 2000 2:16 PM
To: John Boyer; Petteri Stenius; 'merlin'
Cc: XML
Subject: 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

Received on Tuesday, 15 August 2000 18:52:09 UTC