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

RE: Sorting of DOM input to c14n 2.0

From: Scott Cantor <cantor.2@osu.edu>
Date: Tue, 13 Apr 2010 15:45:27 -0400
To: "'Pratik Datta'" <pratik.datta@oracle.com>, "'Meiko Jensen'" <Meiko.Jensen@rub.de>
Cc: <public-xmlsec@w3.org>
Message-ID: <00b201cadb41$de0f9200$9a2eb600$@2@osu.edu>
> 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.

I think your first sentence is backwards, no? You're saying to leave it on
the c14n side?

That's fine, I just advocate the processing rules being less
implementation-specific about sorting and more declarative (the subsets must
be processed in order).

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

Well, this is why I'm not an advocate of prefix-rewriting, and I don't think
it should be MTI.
-- Scott
Received on Tuesday, 13 April 2010 19:46:03 UTC

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