Re: Comment for XML Signature Syntax and Processing Version 1.1 Working Draft 18 October 2012 (re: here() function)

At 2012-11-08 20:49 +0000, Frederick.Hirsch@nokia.com wrote:
>This issue was noted in 2002, but no namespace was 
>added: 
><http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002OctDec/0033.html>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002OctDec/0033.html 
>
>
>It looks to me that the intent is to augment the XPath library with 
>the here() function without a namespace prefix - possibly the 
>original thinking was that it would be added to the standard XPath 
>library but there is no documentation of that thinking (perhaps Ed 
>or Brian remember).
>
>The current text in section 6.6.3 says in the bullet list:
>    * A library of functions equal to the function set defined in 
> [<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#bib-XPATH>XPATH] 
> a function named 
> <http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#function-here>here.
>
>This corresponds to the idea that the library is augmented with 
>here() and thus it should not be prefixed, but treated by the 
>implementation as if it were part of XPath.
>
>Thus an implementation of signature should treat an XPath 
>implementation as having here() as part of the library. This also 
>avoids the potential of  namespace wrapping attacks noted by Meiko, 
>http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0000.html
>
>Thus could we argue no change is needed apart from the editorial fix 
>to the bullet to read as follows:
>    * A library of functions equal to the function set defined in 
> [<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#bib-XPATH>XPATH] 
> augmented with a function named 
> <http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#function-here>here 
> to be treated as if part of the library (and not namespace prefixed).
>Regardless of how an implementation is built is will need to augment 
>the XPath library with here() to support XML Signature.
>
>Thoughts?

This was raised in another email thread, using the evidence that XSLT 
and XQuery are two languages that augment without conflicts the list 
of available functions in an XPath implementation with function names 
in no namespace.

I acknowledged that as suitable evidence for the established practice 
of a specification augmenting XPath with their own functions.  But I 
noted my initial concerns were that this might be a restriction for 
off-the-shelf XPath implementations.  I now think DigSig joins XSLT 
and XQuery as precedents for off-the-shelf XPath implementations to 
allow the no-namespace function list to be augmented.

I still question if some implementers might have problems rewriting 
the transform expression in "pure XPath" to implement some task, but 
I guess that just goes with the territory.

In that other email thread I noted I was mollified by this argument 
of established practice.  I'm prepared to withdraw my concerns.  I do 
not have credentials to <public-xmlsec@w3.org> in order to post that 
the issue appears to have been properly addressed from the start and 
that my worries were unfounded.

Thank you for your patience with me.

. . . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/m/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Received on Thursday, 8 November 2012 21:04:07 UTC