- From: Petteri Stenius <Petteri.Stenius@remtec.fi>
- Date: Mon, 15 May 2000 22:16:06 +0300
- To: "'John Boyer'" <jboyer@PureEdge.com>
- Cc: "IETF/W3C XML-DSig WG (E-mail)" <w3c-ietf-xmldsig@w3.org>
I think it would be good if the XPath serialization and c14n were closer to each other, or even equal! I'm not saying I need a c14n after a XPath transform, I'm saying that the whole process of doing an XPath transform is not possible in one pass. A simple example should clarify: <A> <B>text</B> <Signature Id="S1"> </Signature> </A> The result node-set from the XPath expression for excluding the Signature element is a list with the nodes: A B text The serialized output from the XPath expression is: <A><B>text</B></A><B>text</B>text Output from the combination of exclude-signature transform + C14N serialization is simply: <A><B>text</B></A> Petteri > -----Original Message----- > From: John Boyer [mailto:jboyer@PureEdge.com] > Sent: Thursday, May 11, 2000 10:17 PM > To: Petteri Stenius; 'Joseph M. Reagle Jr.' > Cc: IETF/W3C XML-DSig WG (E-mail) > Subject: 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 >
Received on Monday, 15 May 2000 15:16:27 UTC