RE: Enveloped signatures

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/
>
>

Received on Wednesday, 10 May 2000 11:52:57 UTC