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

Re: Enveloped Signature Transform, XPath Transform: function here()

From: merlin <merlin@baltimore.ie>
Date: Fri, 11 Aug 2000 15:11:19 +0100
Message-Id: <200008111411.PAA16764@cougar.baltimore.ie>
To: "Gregor Karlinger" <gregor.karlinger@iaik.at>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>

Hi Gregor,

See [1] and followups [2]. There are also previous comments on this.
There are requirements whereby here() or some equivalent function
is required [3]. A proposed solution exists [4] and there was some
discussion at IETF [5] but I can't tell what the outcome was. I
suspect that this will be further discussed in the upcoming
teleconferences [6].

Merlin

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0105.html
[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/thread.html
[3] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0142.html
[4] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0168.html
[5] http://www.w3.org/Signature/Minutes/000803-Pittsburgh/
[6] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0228.html

r/gregor.karlinger@iaik.at/2000.08.11/12:48:53
>Hi all!
>
>I am facing severe troubles with implementing the REQUIRED
>Enveloped Signature Transform, since it violates (in my
>opinion) the basic concept of transforms:
>
>1. A transform has one implicit parameter: An octet stream
>   form the Reference or the output of an earlier Transform.
>
>2. All other parameters can be specified via the XML content
>   of the Transform element.
>
>3. There are no other means to tell the Transforms about 
>   additional parameters.
>
>Now, if I have to implement the Enveloped Signature Transform,
>I cannot compute the result of the function here(), which is
>used in the XPath expression for this transform. It makes
>no difference if I implement the transform using a XPath
>engine or with other means: 
>
>The result of here() should be the node which 
>bears the XPath expression. But it is impossible to get this
>result into the Transform, since a Transform operates on
>Octets and not on a tree.
>
>Of course it is possible to write a hack, in which the Transform
>implementation has access to the tree where the XPath expression's
>parent resides, and which does not operate on a Octet input stream.
>
>But, it IS a hack, and does not fit in the concept of Transforms,
>which should be a generic mechanism as described above.
>
>I don't see any really good reason to provide the Enveloped Signature
>Transform at all, since the author should know where the Signature
>element resides in the XML document, and can cut it out by means
>of an XPath transform, which does not contain the here() function.
>At least we should consider not to make this Transform REQUIRED. 
>
>Finally, the same problem applies to the XPath transform itself, because
>this sinister here() function is added to the function library by
>our specification.
>
>Regards, Gregor
>---------------------------------------------------------------
>Gregor Karlinger
>mailto://gregor.karlinger@iaik.at
>http://www.iaik.at
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications
>Austria
>---------------------------------------------------------------
> 
>
Received on Friday, 11 August 2000 10:11:38 GMT

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