W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

RE: Enveloped signatures

From: Petteri Stenius <Petteri.Stenius@remtec.fi>
Date: Thu, 11 May 2000 00:55:22 +0300
Message-ID: <CD0FF8F92CA8D311B9AB00105A14D5570B10B5@server.remtec.fi>
To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>
Cc: "IETF/W3C XML-DSig WG (E-mail)" <w3c-ietf-xmldsig@w3.org>


Yes, I completely agree with you that it would be elegant to define this
transform by means of a XPath expression, and I must admit that I am one of
those who has been suggesting this approach.

But given the experience from actually implementing XPath transformation I
would say that it is awkward, both to implement and because of performance
reasons. The XPath algorithm does not allow single pass
transformation+canonicalization over the referenced XML document. C14N and a
properly defined exclusion transform would allow that. (Single pass here
means a single traversal of a parsed DOM tree.)


Petteri


> -----Original Message-----
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: 10. toukokuuta 2000 15:29
> 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 17:55:32 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT