RE: Enveloped signatures

I would be interested in knowing exactly why you feel you need c14n after an
XPath transform.  After running the XPath expression, the result of
serialization is quite similar to c14n in most respects and was written so
that there would be no output ambiguities that did not result from changing
the input document.  You should not need c14n, so one pass should be
sufficient.

Moreover, it seems that we are inheriting the c14n spec, and the two
principal differences between the XPath serialization and c14n, which are
namespace normalization and composed character normalization, are quite
likely to be deleted (for reasons that will be discussed later).  Assuming
this is true, though, means that the XPath serialization will, in essence,
be equal to c14n.

Thus, the only area of awkwardness that we are trying to overcome is the
'political' awkwardness of having applications provide support for a
specific XPath exclusion transform without providing full XPath support.

I don't mind if we want to do this, but the WG has avoided doing this in the
past because it has, up to now, meant that we would have to repeat the
definition of 'how to write' the result.  It's one thing to say 'I just want
to exclude the Signature being created while calculating this DigestValue'
but it's another thing entirely to recognize that you must still create a
byte stream that can be digested.

In other words, the enveloped-signature-transform still needs something like
the XPath serialization to fit our current processing model.

John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Petteri Stenius
Sent: Wednesday, May 10, 2000 2:55 PM
To: 'Joseph M. Reagle Jr.'
Cc: IETF/W3C XML-DSig WG (E-mail)
Subject: RE: Enveloped signatures




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 Thursday, 11 May 2000 15:16:36 UTC