W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2010

RE: Sorting of DOM input to c14n 2.0

From: Pratik Datta <pratik.datta@oracle.com>
Date: Tue, 13 Apr 2010 12:11:53 -0700 (PDT)
Message-ID: <b29132b2-f973-48ed-ba66-2a4e9cfe4889@default>
To: Scott Cantor <cantor.2@osu.edu>, Meiko Jensen <Meiko.Jensen@rub.de>
Cc: public-xmlsec@w3.org
>From the complexity point of view I think it is better to put in on signing side than on the c14n side, because I think a simple implementation will use an off the shelf Xpath engine on the signing side, and write custom code for the c14n side.  If we put the sorting on the signing side then they would need to write some custom code on the signing side too.  Another fact is that c14n 1.x implementation is already required to document order sorting, so it is probably not too much to expect a c14n 2.x to do so too.  A full blown c14n 2.0 implementaion with all prefix rewriting and pruning and sorting will turn out to be more complicated than a c14n 1.x implementation (especially when implemented in Ruby)  but we can profile it down to the n=1 case.


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, April 13, 2010 11:49 AM
To: Meiko Jensen; Pratik Datta
Cc: public-xmlsec@w3.org
Subject: RE: Sorting of DOM input to c14n 2.0

> However, I'd wonder why an XPath evaluator should permute the document
> order in such settings. => Do we need to explain this in the spec?

I think it's worth noting, myself, but I also think it's not out of the
realm of possibility to specify the sort and "no subsets contained in other
subsets" assumptions on the signing side (the "caller") vs. the c14n side
(the "callee").

That enables a simpler subsystem for c14n, and the opportunity to avoid work
when the calling code knows it's not required or has prior knowledge of the

But I realize that the common case for not having to worry about it is when
n=1, in which case it makes no difference.

Just a thought.

-- Scott
Received on Tuesday, 13 April 2010 19:14:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:13 UTC