Re: Issues with XML Dig Sig and XML Canonicalization

Hi all,

our goal in the OASIS DSS group is make the living with DSig as easy as possible ! 

That's why we made a spec to easily access a crypto server component by webservice and forget about signature standards, algorithms, validity dates ...
 
My company build a open sourced server implementation of the DSS spec and moreover we implemented the widget signature spec. And to make the programmer feel comfortable we added an ant task that takes the jar and applies the signature by calling the DSS server. The build process remains as usual, the developer can concentrate on wigdet functionality. Moreover the certificates are in a save place ( on the server ) and only the admnistrator has to care about expiry days. But that's his daily business, if there is SSL around.

Yes, this smells a bit like "the tools will save us", but we are all using compilers day in and day out. I don't know how to write a compiler nevertheless I use them. So neither compilers nor signing facilities should to be a concern for the widget group ! 

So just use what's there. And XMLDSig is there !

Btw: We also got the J2SE code signing spec ( jar signing ) implemented. I don't think that's much better solution for widgets. It's just strange in other ways ...

Greetings

Andreas

----- original Nachricht --------

Betreff: Issues with XML Dig Sig and XML Canonicalization; was Re: Rechartering  WebApp WG
Gesendet: Fr, 12. Feb 2010
Von: Marcos Caceres<marcosc@opera.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
> 
> 

--- original Nachricht Ende ----

Received on Friday, 12 February 2010 14:54:41 UTC