RE: Sorting of DOM input to c14n 2.0

>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.


Pratik




-----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
order.

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