W3C

Disposition of comments for the XML Security Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2721 G. Ken Holman <gkholman@CraneSoftwrights.com> (archived comment)
I'm resending this, as plain text, because the Web archive doesn't seem
to have stored the message properly...

-------- Original Message --------
Subject: Fwd: Comment for XML Signature Syntax and Processing Version
1.1 Working Draft 18 October 2012 (re: here() function)
From: <edsimon@xmlsec.com>
Date: Fri, November 02, 2012 12:01 pm
To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>,
public-xmlsec@w3.org

G. Ken Holman of Crane Softwrights (copied) has noticed an issue
(detailed below in Ken's email) with the definition of the here()
function in XML Signature. After Ken brought this to my attention, I
have been wondering if the namespace injection/wrapping issue [1] [2]
that Meiko and I investigated might be applicable to this issue (and
thus make it more important than just a "function not found" problem).


Ed

[1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0000.html

[2] http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0005.html

-------- Original Message --------
Subject: Comment for XML Signature Syntax and Processing Version 1.1
Working Draft 18 October 2012
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Date: Wed, October 31, 2012 7:00 pm
To: <edsimon@xmlsec.com>
...

Attn: Editors of XML Signature Syntax and Processing Version 1.1
Re: Working Draft 18 October 2012

Since version 1 of XML Signature there has been a glaring (to me)
error in the specification of the "here()" function, in that it was
never properly named using a namespace qualification.

Languages that use XPath typically assume that unprefixed function
names are functions in the XPath library and that functions outside
of the XPath library must be prefixed with a namespace qualification
of some kind. Certainly XSLT and XQuery impose this
constraint. Indirectly so does Schematron. Such a constraint has
not been a part of XMLSec.

The (low probability) issue is that who knows what future versions of
XPath might include in a function named "here" of its own? It would
be unavailable to users of XMLSec (or, worse, implement some
unexpected future semantic).

The (guaranteed probability) issue is that a general-purpose XPath
analyzer looking at the expression would flag the "here()" as a
syntax error because the unprefixed function is not part of the
standard library.

Standalone XPath processors may soon be available. Implementers of
XMLSec who want to use such a processor are going to be challenged
since the expression will trigger "function not found" errors when
analyzed.

But I acknowledge that there is already an established base of using
"here()" with XML Signature 1.0.

My thought is that "here()" could continue to be allowed for backward
compatibility, but would be deprecated from now on in favour of
something like "ds:here()" (where, of course, the prefix is
irrelevant but it is mapped to the signature namespace).

Then, a general-purpose XPath processor would look for the function
named "{http://www.w3.org/2000/09/xmldsig#}here()" in the set of
statically-defined function signatures provided by the application
invoking the XPath processor:

http://www.w3.org/TR/2007/REC-xpath20-20070123/#static_context
[Definition: The static context of an expression is the information
that is available during static analysis of the expression, prior to
its evaluation.] This information can be used to decide whether the
expression contains a static error. If analysis of an expression
relies on some component of the static context that has not been
assigned a value, a static error is raised [err:XPST0001].

http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-function-signature
[Definition: Function signatures. This component defines the set of
functions that are available to be called from within an expression.
Each function is uniquely identified by its expanded QName and its
arity (number of parameters).] In addition to the name and arity,
each function signature specifies the static types of the function
parameters and result.

http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-function-calls
[Definition: The built-in functions supported by XPath are defined in
[XQuery 1.0 and XPath 2.0 Functions and Operators].] Additional
functions may be provided in the static context. XPath per se does
not provide a way to declare functions, but a host language may
provide such a mechanism.
...
A function call consists of a QName followed by a parenthesized list
of zero or more expressions, called arguments. If the QName in the
function call has no namespace prefix, it is considered to be in the
default function namespace.

http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-def-fn-ns
[Definition: Default function namespace. This is a namespace URI or
"none". The namespace URI, if present, is used for any unprefixed
QName appearing in a position where a function name is expected.]

Having the function name namespace qualified would allow the
expression to be rewritten in an XPath context without having first
to inspect the expression for the errant (to the XPath processor)
"{}here()" syntax. As it stands today, there is a burden on
implementation to prevent the "{}here()" function from getting to an
XPath library written as it is for fear of triggering a static error
"err:XPST0001".

I hope this is helpful.

G. Ken Holman
gkholman@CraneSoftwrights.com
http://www.CraneSoftwrights.com/bio

--
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
http://lists.w3.org/Archives/Public/public-xmlsec/2012Nov/0009.html

The current text in section 6.6.3 says in the bullet list:

* A library of functions equal to the function set defined in [XPATH<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#bib-XPATH>] a function named here<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#function-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 [XPATH<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#bib-XPATH>] augmented with a function named here<http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/#function-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.
yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:45:23 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org