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 15:52:02 -0700
To: "Kevin Regan" <kevinr@valicert.com>, "Petteri Stenius" <Petteri.Stenius@done360.com>, "'merlin'" <merlin@baltimore.ie>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>
Hi Kevin,

Actually, XPath was not introduced to do canonicalization and enveloped

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'
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
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 18:52:09 GMT

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