W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

RE: History: Question on C14N list of nodes instead of subtrees

From: John Boyer <JBoyer@PureEdge.com>
Date: Fri, 25 Jan 2002 08:44:20 -0800
Message-ID: <7874BFCCD289A645B5CE3935769F0B52350084@tigger.PureEdge.com>
To: "merlin" <merlin@baltimore.ie>
Cc: <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>
Hi Merlin,

If there's some way you could run those tests, I'd certainly appreciate
knowing the outcome.  The concern I have is that, right now in XFDL, our
logical equivalent to an XPath transform runs in microseconds, even on
XML that could be a megabyte in size.  There's no way we could tolerate
a hundred-fold increase in run-times on server side CPUs just to use
XPath for signature filtering.  

Even if we have to modify the XPath transform (or add a new transform)
because of some unexpected lapse in real-world usability, it would be
far better to bite the bullet and make that change than it would be to
essentially lose the ability to do document subsetting because of speed

Most are interested in being able to efficiently specify a subtree to
sign, but I assure you that it would be a mistake to not have equivalent
efficiencies for exclusive logic signature filter (e.g. sign everything
except a given subtree or subtrees).  The good news is that, if we do
end up with some design change necessity, it would be relatively easy on
implementers to accommodate both needs.  I just want to make sure
everyone remains aware of both needs in any such considerations.

Joseph, do you have any opinion on the ability to tolerate a change at
this point?

John Boyer
PureEdge Solutions Inc.

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Thursday, January 24, 2002 8:00 PM
To: John Boyer
Cc: reagle@w3.org; w3c-ietf-xmldsig@w3.org
Subject: Re: History: Question on C14N list of nodes instead of subtrees

>I'm not averse to more transforms; it would be useful to get an idea
>how much motivation there might be to make changes at this point.  My
>position is that 
>	if the problem is important enough (e.g. good idea but too slow
>in a frequently occuring scenario), and
>	if it is easy for the implementations to be tweaked, 
>	then let's fix it before REC.
>So, before we stop the presses and re-architect anything, it would be
>useful to find out exactly how important the problem is.  By this I
>the mundane question of how frequently occuring the scenario is, but
>also the more interesting question of whether the slowness is really an
>inherent limitation we are hitting with XPath or just an implementation

I don't think that we need to change the spec or anything;
we can just throw up a new doc like exclusive c14n, or even
just add to the extra algorithms doc. I may try running
some tests if I have the time.


Baltimore Technologies plc will not be liable for direct,  special,
or consequential  damages  arising  from  alteration of  the contents of
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Friday, 25 January 2002 11:45:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC