- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 11 Feb 2010 02:42:28 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Webapps WG <public-webapps@w3.org>
On Feb 11, 2010, at 2:10 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres <marcosc@opera.com> > wrote: >>>>>> I'm sooooooo totally for that. I want nothing more than to have >>>>>> more >>>>>> engagement and input from you guys. Our URI spec is in last >>>>>> call and so >>>>>> is >>>>>> the access request spec. The specs are really small. Please >>>>>> find a few >>>>>> hours >>>>>> and help us align if we haven't already. It's never too late to >>>>>> comment >>>>>> and >>>>>> help us fix stuff if it's borked. We are doing the best we can >>>>>> here, >>>>>> and >>>>>> certainly don't want to go against the web security model. >>>>> >>>>> It's funny that you say that, because last I commented on a widget >>>>> spec was in relation to the signing spec. I then expressed >>>>> dislike for >>>>> the use of xml canonicalization and, IIRC, a few other non-trivial >>>>> aspects of the spec. But was told that the spec was too far >>>>> along and >>>>> it was too late to change :-) >>>> >>>> That is correct. Many members working on widgets believed that >>>> the use >>>> cases >>>> were met by XML digsig (even with it's reliance on xml >>>> canonicalization) >>>> and >>>> I was led to believe that it is in fact implementable. I know of >>>> one >>>> implementation thus far, so the jury is still out. It's still too >>>> early >>>> for >>>> me to say if it was a mistake to take XML digsig over JAR >>>> signing. If it >>>> proves a mistake (I.e., no one implements), then it's logical to >>>> look for >>>> alternatives. I won't claim to understand the xml canonicalization >>>> issue, >>>> but people I talk to still tell me it won't be a problem. You >>>> want to add >>>> some tests to the test suite?:) >>> >>> I don't doubt that it's implementable. However I still think there >>> are >>> much simpler solutions that make things easier both for authors and >>> browser implementors. See for example the way that mozilla signs XPI >>> files. >> >> 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 ;) Ooooh, snap!! walked straight into that one :D > > 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. It's crypto: by definition, its really complicated; I don't know how much easier one could make it. And reading https://developer.mozilla.org/en/Signing_a_XPI I can see Mozilla's solution is far from easy to use. I was expecting point and click, but I see a lot of scary (for me) command line stuff. One even need a special zip tool because of the whole META/ inf thing? > What about situations when you want to dynamically generate widgets, > say using PHP? What about it? Won't a simple command line tool work? You could have a GUI version and a command line version. Like Zip. > Or if you don't speak the language(s) the tool is > localized to. I don't understand this one? I guess as above. > Or if a web-based tool happens to be down because of > server upgrades? I'm sorry, but i'm not really following as to what this has to do with our choice to use XML DigSig as the sig format? Despite my silly tools will save us mishap, my original question is still: is XML digsig limited in some way that all the above command/GUI/web interfaces could not be built on it (if they haven't already)? And what are the advantages of XPI signing over the current model? Is it the availability of tools to make sigs what makes it better or is it that the sig format simpler? I can't see it being too much simpler from an authors perspective. And once you implement it and get it running, won't the XML cononicalization problems go away? >
Received on Thursday, 11 February 2010 01:44:04 UTC