- 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>
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 UTC