W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Issues with XML Dig Sig and XML Canonicalization; was Re: Rechartering WebApp WG

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 12 Feb 2010 15:07:48 +0100
Message-ID: <4B7560B4.1070900@opera.com>
To: Scott Wilson <scott.bradley.wilson@gmail.com>
CC: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Henri Sivonen <hsivonen@iki.fi>, Frederick Hirsch <Frederick.Hirsch@nokia.com>
(Dragging Henri Sivonen in, as he originally raised some of the issues 
below and I'm sure he would like to be involved. Also dragging Frederick 
Hirsch in, as he co-edited Widgets Dig Sig spec and co-editor of the XML 
Signature Syntax and Processing Second Edition)

Scott Wilson wrote:
>
> On 11 Feb 2010, at 01:10, Jonas Sicking wrote:
>
>>> I don't disagree with you on the implementation side (and Im happy to
>>> hear
>>> that you think it can be implemented - I'll keep my fingers crossed).
>>> On the
>>> author side, I honestly don't know how much of a difference it will
>>> make.
>>> I'm sure someone will create a dead easy click once packager for
>>> widgets, if
>>> they haven't done so already. But is there something inherently wrong
>>> with
>>> our current technological choice that would not allow that? (if yes,
>>> please
>>> send to public-webapps, which is where we discuss widgets ;))
>>
>> Ah, the old "the tools will save us" argument ;)
>>
>> Yes, tools can certainly help. But that doesn't remove from the fact
>> that something that's simpler to author would be simpler for authors.
>> What about situations when you want to dynamically generate widgets,
>> say using PHP? Or if you don't speak the language(s) the tool is
>> localized to. Or if a web-based tool happens to be down because of
>> server upgrades?
>>
>> / Jonas
>>
>
> I've run two "build a W3C widget" events now for Wookie, one for
> students (mostly education/social sci students, not computer
> scientists!) and one for developers. No complaints about them being too
> complicated to make; pretty much everyone had learned the tech and made
> one in 90 minutes.

Did they digitally sign the widget too?

> So where's the issue?

There is no "issue", we are just doing a comparison for argument's sake 
at this point.

What we are discussing is if Mozilla's solution for signing Zip files 
(JAR-based) [1] is easier for vendors to implement/maintain and authors 
to deal with when compared to the W3C Widget solution of using XML Dig 
Sig. If it's easy to build a widget is a different matter (and I very 
much doubt that anyone would argue that making a widget is hard - It's 
so easy, in fact, that Opera once put the instructions for building a 
"Hello World!" widget on a business card! - so yeah, it's easy:)).

Thus far, in terms of ease of use for authors, little in the way of 
concrete evidence has been presented of one signing method being easier 
than the other (specially by looking at the complexity of using 
Mozilla's command line-based tool [1] compared to BONDI's SDK [2]). This 
is not to say that Mozilla (or anyone, given its open source nature) 
could not make a super easy tool for signing zip files.

However, the proof is in the pudding here: By virtue that Bondi's SDK 
includes a tool that allows widgets to be signed with a few clicks is 
evidence that the W3C's Widgets Signature specification is capable of 
being used to produce easy to use products. And by virtue that Kai 
Hendry has created scripts that could allow widgets to be 
signed/verified over the Web is evidence that tools can that address 
Jonas' case of widgets being dynamically generated on the server side 
and signed dynamically. I know the tools won't save us, but the fact 
that tools now exists that do what the WG predicted it would ("click, 
click, done!" and allow widgets to be dynamically signed on the 
server-side) serves as strong evidence that the choice of using XML Dig 
Sig was the right one for the authoring use cases and design goals [3]: 
we wanted ease of use and we got it! now we want interop, and we are 
hopeful we will get it. That leads to the next point...

In terms of implementation, Mozilla has previously raised concerns about 
XML canonicalization (which I don't fully understand, hence the growing 
email cc list) - but by the virtue that people have implemented the 
Widget signing spec, I await to see if Mozilla's concerns will 
materialize in practice and actually hinder interoperability - I'm not 
saying this is FUD, but we need proof. It's too early to make the call 
that widget signing is flawed. And it's important to note that no one 
that has implemented has come back to the WG raising any concerns or 
screaming bloody murder. However, as no test suite exists yet, we are 
hopeful that those that have experience and understand the 
canonicalization issues with XML (*cough, cough, Henri Sivonen, 
cough*:)) will help us build test that expose the interoperability 
issues so that that we can address them for real.

Without the test that actually expose the limitations of XML 
canonicalization and XML Dig Sig, we can talk about this till the cows 
come home. So, can anyone help with a few tests?

Kind regards,
Marcos

[1] https://developer.mozilla.org/en/Signing_a_XPI
[2] http://bondisdk.limofoundation.org/
[3] http://dev.w3.org/2006/waf/widgets-reqs/
[4] http://git.webvm.net/?p=wgtqa;a=tree;f=xmldsig
Received on Friday, 12 February 2010 14:08:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT