W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2012

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

From: Sean Mullan <sean.mullan@oracle.com>
Date: Fri, 2 Nov 2012 12:24:51 -0700 (PDT)
Message-ID: <50941E03.2060408@oracle.com>
To: "Cantor, Scott" <cantor.2@osu.edu>
Cc: "edsimon@xmlsec.com" <edsimon@xmlsec.com>, "G. Ken Holman" <gkholman@cranesoftwrights.com>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
On 11/02/2012 03:10 PM, Cantor, Scott wrote:
> On 11/2/12 3:02 PM, "Sean Mullan" <sean.mullan@oracle.com> wrote:
>
>> Hmm, I knew this issue looked familiar. I actually reported this as an
>> issue way back in 2004 and here was the explanation:
>>
>> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2004JanMar/0057.html
>>
>> I'm still not sure what the right answer is.
>
> This sentence in the response seems unsupportable in aa typical
> implementation, I would think:
>
> "If other functions were available and were used during signing, then
> there would be interoperability problems during validation, so no other
> functions are allowed in the evaluation context."
>
> That sounds like a dubious constraint to expect to be in place using off
> the shelf components. But I'll defer to the experts.

Yes, I guess technically the response might be correct, but when you are 
trying to build a DSig implementation with reusable parts such as JAXP, 
it doesn't work, in particular the XPathFunctionResolver [1] interface 
of the JAXP XPath API cannot be used to directly implement that 
functionality, because it requires it to be namespace qualified.

--Sean

[1] 
http://docs.oracle.com/javase/7/docs/api/javax/xml/xpath/XPathFunctionResolver.html
Received on Friday, 2 November 2012 19:28:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 2 November 2012 19:28:04 GMT