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].


[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

>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
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications
Received on Friday, 11 August 2000 10:11:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC