Re: Fix for RE: XMLDSIG proposal: enveloped signatures, xpath and here()

At 11:29 7/26/2000 -0700, John Boyer wrote:
  >In total, we could
 >1) drop here() from the XPath transform
 >2) rewrite the enveloped signature specification to use a Reference with an
 >Xpointer URI that is equal to the current XPath for enveloped signature.
 >3) Convert the resulting location-set to a node-set (throw error if there
 >are any point, range or other non-node parts of the location-set)
 >4) C14N the resulting XPath node-set.

Point 4, do you mean canonicalizing the XPtr node-set?

 >We have assumed that people can use a URI that
 >includes at least a barename Xpointer.  But the result of a barename
 >XPointer is a *location-set*, not an octet stream.  To fix this, I believe
 >we have assumed that the canonicalized result of the barename xpointer
 >be passed to the transforms (at least I have). 

Can you point me to a definition of location-set? (Node set is at least
mentioned in XPath but I can't find location set in XPath, XPtr or Infoset.)

 > But c14n operates on a
 >node-set, not a location-set.  However, certainly in the case of barename
 >xpointer, the location-set is a node-set (there are no non-nodes), so
 >canonicalizing it presents no real problems.
Do I understand the situation correctly?

PRESENT: We defined Enveveloped-Signature transform using XPath since we are
already using the XPath data model and an expression to derive the Canonical
form. This is rather elegant. However, while we defined the
Enveloped-Signature transform using XPath, XPath isn't necessary for
implementation. This approach makes it easy for those that have an XPath
implementation (the definition of enveloped implements this feature!) and no
more harder for those that implement this feature otherwise (the XPath spec
plus the definition tells them what they must do in their own
implementation, but not how to do it.)

However, we found that the XPath expression (and employment of here() in
that context) doesn't do the job well. However, we could do the job by
expressing it as point of XPtr, however, we've been trying to avoid reliance
upon XPointer. The question is:

PROPOSAL/QUESTION: Would moving to XPtr for this feature be much more
A. Again, an XPtr implementation isn't necessary, the relevant part of the
XPtr and our own expression defines the Enveloped feature. For those that
have an  XPath implementation, Merlin asserts, "Technologically, all
verifiers which support XPath transforms contain the necessary tools for
XPointer resolution. So adding a need for this is a minimal burden" so the
job should be easy. (Do others agree?) Those that were "hand-coding" the
enveloped signature feature before, will do the same now (and I think this
won't increase their job all that more either.)
B. In Merlin's proposal he expressed the expression as:
>   <Reference URI='#xpointer(../../previous-sibling)'>
Is this purposeful, as URI="#xpointer" is discouraged [2] and should be
placed in a seperate transform:
<Reference URI=''>
   <Transform Algorithm=""/>

Otherwise, support of other fragment/MIME types (e.g., PDF) or XML
addressing mechanisms (e.g., [XPath, Xptr]) is OPTIONAL, though we RECOMMEND
support of [XPath]. Regardless, such fragment identification and addressing
SHOULD be given under Transforms (not as part of the URI) so that they can
be fully identified and specified.

Joseph Reagle Jr.   
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair

Received on Wednesday, 2 August 2000 11:57:34 UTC