RE: Enveloped signatures

Good point! But we have decided not to require XPtr... However, it still
might provide enough 'elegance' in defining the behaviour, but I'm not sure
if we could also reproduce that in XPath for those that plan on doing XPath
solution. I'll defer to John on that.

At 11:54 2000-05-10 -0400, Mariano P. Consens wrote:
 >
 >Joseph (and Donald and John, who were also part of the discussion after the
 >meeting),
 >
 >I've found the following function defined in XPointer (Working Draft 6
 >December 1999):
 >
 >FUNCTION: location-set here( )
 >The here() function returns a location-set with a single member. That
 >location is of type element, and locates the element that directly contains
 >(as text) or bears (as an attribute value) the XPointer. This expression
 >results in a syntax error if the containing XPointer does not appear in an
 >XML document.
 >
 >Using it we can find the ancestor Signature element (without defining
 >variable bindings) as:
 >
 >here()/ancestor::Signature
 >
 >Mariano.
 >
 >  --------------------------------------------------------------------
 >  Mariano P. Consens                    Department of Computer Science
 >  e-mail: mconsens@uwaterloo.ca         University of Waterloo
 >  phone: (519) 888-4567 x-3023          Waterloo, Ontario, N2L 3G1
 >  fax: (519) 885-1208                   CANADA
 >  --------------------------------------------------------------------
 >
 >
 >> -----Original Message-----
 >> From: w3c-ietf-xmldsig-request@w3.org
 >> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
 >> Jr.
 >> Sent: May 10, 2000 8:29 AM
 >> To: Petteri Stenius
 >> Cc: IETF/W3C XML-DSig WG (E-mail)
 >> Subject: Re: Enveloped signatures
 >>
 >> At 11:35 2000-05-10 +0300, Petteri Stenius wrote:
 >>  >6.6.5 Signature Exclusion
 >>  >
 >>  >Identifier:
 >>  >    http://www.w3.org/2000/02/xmldsig#exclude-signature
 >>  >
 >>  >The transform excludes the ancestor Signature element of the
DigestValue
 >>  >element that is being calculated. The intention is to support enveloped
 >>  >signatures where the DigestValue calculation would overlap with itself.
 >>
 >> Petteri, the idea was that it would be somewhat elegant if we
 >> specified the
 >> identifier and defined its behavior using an XPath expression (the
 >> equivalent of your natural language text above). That way, people
 >> that don't
 >> expect to implement XPath can implement the feature rather simply; those
 >> that already have XPath don't have to do something special, and both will
 >> interoperate!
 >>
 >> The challenge then is to find the XPath equivalent of your description
 >> above. This seemed to be potentially tricky in that the context
 >> node in your
 >> description above is "the ancestor Signature element of the DigestValue
 >> element that is being calculated" and if you go the XPath/XML route, it
 >> isn't going to know this (what is being calculated), you just hand it
XML.
 >> Then the XPath processor sets the context node at the root root, and then
 >> you have to specify an expression that finds and excludes the right
 >> Signature (if they are nested.) There might be a clever way to do this
 >> though, and I think Boyer might've mentioned you might be able to achieve
 >> this by passing arguments from a function ... ? But we concluded by
saying
 >> let's give it some thought and discuss it on the list.
 >>
 >> At the meeting, we had agreement to include this feature in the Candidate
 >> REC / Proposed Draft, I'm waiting/hoping/thinking about if we can
 >> define it
 >> as an XPath expression as well.
 >>
 >> _________________________________________________________
 >> Joseph Reagle Jr.
 >> W3C Policy Analyst                mailto:reagle@w3.org
 >> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
 >>
 >>
 >

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Thursday, 11 May 2000 15:35:22 UTC