On Sep 21, 2012, at 1:10 PM, C. Scott Ananian wrote: > On Fri, Sep 21, 2012 at 12:44 PM, Andy McKay <[email protected]> wrote: >> >> On 20/09/2012, at 6:22 PM, Jonas Sicking wrote: >>> What makes you think that we're not using a signed jar format? I don't >>> know exactly what the signature format looks like as I don't have >>> enough crypto chops, but I'm pretty sure we're trying to make it as >>> standard as possible. >> >> A signing format for packaged apps hasn't been defined yet and I'm hoping we >> can get that sorted out soon. I'm keen on using an existing structure we >> have already as much as possible. Similar to what exists for App receipts or >> Addon signing. > > Two things: > > 1) I think you've missed one of the main points of my alternative > proposal above: by using standard SSL to authenticate online > installation, no code signing is needed in the common case, nor is > there any special format or tool needed for 90% of the use cases. > This includes web stores: the web-consistent way to do this is to > serve apps from subdomains of the web store, for example: > > https://twitter.my-appstore.us/manifest.webapp > https://twitter.my-appstore.us/resources.zip
Here are a few reasons why we want to sign packages: 1) it allows us to scale up our global package delivery by hosting packages on multiple CDN mirrors which would be on different domains having different https certs. 2) It reduces the attack surface because we can host a single signing server with a rigid security model. If we were to rely on https alone then many successful attacks to the web server could compromise signed packages. There are probably other reasons but I wasn't a part of the original packaged apps proposal / discussion. As mentioned previously on the thread, many details like the signing algorithm and package format are still up for debate so thanks for the feedback. Also, as the bottom of the wiki states: "[the current proposal] is a good way to start by doing something secure which will give us experience and help us develop something better in the future." > > (of course resources.zip could be unpacked as well, since it's just a > handy shorthand for stuffing an appcache). > > This uses the existing SSL trust hierarchy (and a wildcard cert) for > my-appstore.us to clearly indicate that my-appstore.us trusts this > particular version of the app. No other code signing or verification > is needed. > > The app store can handle multiple versions in whatever way it likes, > leaving this open for 3rd parties to innovate. The most recent > version might always be served, or if some people would prefer not to > immediately update, it might serve apps from (for example): > > https://v1.twitter.my-appstore.us/ > > or some similar scheme. THIS EXPOSES THE VERSION IN THE URI which is > the way the web works. You could do redirections if you wanted > twitter.my-appstore.us to stand for the latest version, etc. This > builds on existing web mechanisms. > > Note that this proposal works well with existing CORS support as well: > twitter.com (or whatever) would use > Access-Control-Allow-Origin: https://twitter.my-appstore.us/ > to indicate that the app sold by my-appstore.us was allowed to use its > resources. > > (If you're not using an appstore, then an SSL certificate for > https://mywebapp.com is sufficient proof that the contents of > https://mywebapp.com/mainfest.webapp and > https://mywebapp.com/resources.zip are good/maintain integrity/etc.) > > 2) Signing a zip would be necessary for off-line verification *only*, > ie someone hands you a USB stick with a zip file on it and you want to > ensure that it's a trusted app. The existing XPI signing mechanism is > not such a great example here, since it's not standardized and no one > other than mozilla uses it, and it's rather cumbersome (read > https://developer.mozilla.org/en-US/docs/Signing_a_XPI if you don't > believe me). What's more, for security purposes the offline signature > mechanism should really use exactly the same chain of trust as the > standard installation mechanism in (1) -- ie, it's a signature which > says that the person who controls https://twitter.my-appstore.us has > certified this .zip bundle as being identical to what was served from > https://twitter.my-appstore.us/resources.zip at some point in time. > (One odd consequence is that this is *not* a "code signing > certificate" it's a normal domain certificate -- which is > substantially more convenient for developers to obtain.) > > Jar files have a much larger installed base, and already used (for > example) with slight variation in the apk package format and the > security chain of trust has been worked out for java web start, etc. > (They typically use code signing certificates, though.) > --scott > > -- > ( http://cscott.net ) > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
