Re: [ubl-security] UBL-XAdES-Profile 1.0-20100501 - Draft 05

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-05-11 12:35 +0100, Andrea Caccia wrote:
>The function here() is defined in 
>http://www.w3.org/TR/xmldsig-core/#function-here 
>in 6.6.3 XPath Filtering where you find:
>...
>         • A library of functions equal to the 
> function set defined in [XPath] plus a function named here.

I see that it is a finalized specification, so I'm a bit flummoxed.

Though I do see in 4.3.3.2:

   "Requirements over XPath processing can include application
    behaviors that are equivalent to the corresponding XPath behavior"

Section 6.1 states:

   "This MAY be implemented via the RECOMMENDED XPath specification
    specified in 6.6.4: Enveloped Signature Transform; it MUST have
    the same effect as that specified by the XPath Transform."

And I see that it *isn't* XPath that is being 
used, but "XPath-Filter 2.0" that is being 
used.  And "XPath-Filter 2.0" is not supported by 
XSLT.  Yet line 258 of your document states a 
typical transform includes XSLT.  That isn't true 
if the function "here()" has to be supported *as 
written*.  If the equivalent of the function is 
allowed to be supported, then perhaps yes you can 
reference XSLT, but any XPath expression that 
mandates the use of "here()" is guaranteed to 
throw an exception by a conforming XSLT processor.

>The XPath we proposed is derived form the 
>standard one and I accept that a different XPath 
>can be defined for dome reasons but this can 
>rise some interoperability problem and who 
>implement a different XPath has take the risk 
>that the recipient could refuse the signature if 
>the verifier is not able to ascertain that the XPath used is a "good" one.

But that is my point.  Using the "here()" 
function may be standard in a digital signature 
processor that recognizes "XPath-Filtering-2.0" 
but is not a "good" XPath expression for any 
other processor.  So making it mandatory 
precludes other processors, like XSLT, from being used *as written*.

It might even be misleading to use the UBL 
<XPath> element, though I see the definition 
makes no normative references to any kind of 
XPath.  The UBL definition reads only "Refers to 
another part of the same document instance" and 
does not constrain the address to be a conforming 
W3C XPath address.  So I suppose I'll accept the 
use of the element named <XPath>.

But I think I see a safe way to proceed.

Right now the instance reads as follows on lines 
501-512, which I think is misleading:

<ds:Transforms>
   <ds:Transform
       Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
     <XPath
       xmlns:odsig="urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0">
       count(ancestor-or-self::odsig:document-signatures |
       here()/ancestor::odsig:document-signatures[1]) >
       count(ancestor-or-self::odsig:document-signatures)
     </XPath>
   </ds:Transform>
</ds:Transforms>

It is misleading because it cites standard XPath 
and includes a non-standard function reference.

I would feel a lot more comfortable if the instance instead read:

<ds:Transforms>
   <ds:Transform
       Algorithm="http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/";>
     <XPath
       xmlns:odsig="urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0">
       count(ancestor-or-self::odsig:document-signatures |
       here()/ancestor::odsig:document-signatures[1]) >
       count(ancestor-or-self::odsig:document-signatures)
     </XPath>
   </ds:Transform>
</ds:Transforms>

... because now you aren't claiming that the 
XPath given can be implemented by standard XPath 
but only by the filtering XPath.  And the 
filtering XPath normatively includes standard XPath.

As an implementer, then, when I see the change 
above, I will know to go to the filter2 
specification and I will find the definition of 
here() and I will have clear guidelines as to 
what to do.  And I will know immediately that it cannot be implemented in XSLT.

I would even accept the XPath with here() as 
mandatory instead of recommended if the Algorithm 
specifies filter2 instead of XPath.

Is that an acceptable compromise?

. . . . . . . . . . . . Ken

p.s. to give you some perspective, I was the 
founding chairman of the OASIS XSLT/XPath 
Conformance Committee and so we had to address 
issues like this from the normative XPath 
specification.  How *other* specifications use 
XPath is up to those other specifications.  So 
I'm firmly of the belief we should specify the 
non-XPath URI and not the standard XPath URI for the algorithm.

--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal