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: Mon, 15 May 2000 22:16:06 +0300
Message-ID: <CD0FF8F92CA8D311B9AB00105A14D5570B10C4@server.remtec.fi>
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 GMT

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