search

w3ctag / packaging-on-the-web

OBSOLETE: Guidance about how to provide packages of information on the web.
60 stars 15 forks source link

Security use cases for packaging #21

Open diracdeltas opened 9 years ago

diracdeltas commented 9 years ago

The intro says:

Initiatives such as Firefox OS and Chrome OS demonstrate the potential of trusted, installable applications built with web technologies. To be used in this way, applications must be self-contained packages of resources that can be tested and signed.

IMO, the ability to verify trusted signatures on packaged apps provides a huge security advantage over regular web apps that don't use packaging. This is part of why many developers who make encrypted messaging apps implement them as browser extensions or Chrome apps instead of as web pages (popular examples include Google's End to End and Cryptocat)

The rest of the document doesn't say anything about signatures, though #8 suggests that the SPF format may include a signature header. FWIW, I don't think it is a good idea to put a signature in a package header or part header, because the content of the other headers should be signed as well. PGP/MIME is an example of how to securely include a signature over a MIME structure (see http://www.ietf.org/rfc/rfc3156.txt, section 5).

Given the importance of signatures, especially for installable apps, it would be nice for this draft to be specific about the signature format and how the client is supposed to verify it. For instance, is the public signing key supposed to be included in the package? Should the client always verify a SPF signature if one is included before loading the resources (this means it has to wait until the entire package is downloaded)? How do signatures interact with caching and partial package updates? etc.

marcoscaceres commented 9 years ago

I'mma just gonna put this here... http://www.w3.org/TR/widgets-digsig/

Cause'... https://www.youtube.com/watch?v=yzLT6_TQmq8

... :dancer:

AFBarstow commented 9 years ago

@marcoscaceres I was wondering the same thing ;-). Do you happen to know if widgets-digsig was ever deployed (in a materialway`), and if it did, how did that go?

jmajnert commented 9 years ago

@AFBarstow I don't know your definition of "material". I know digsig was used in WAC, and now in Tizen web apps.

marcoscaceres commented 9 years ago

@AFBarstow, it was possible to implement in an interoperable manner at least: http://dev.w3.org/2006/waf/widgets-digsig/imp-report/

marcoscaceres commented 9 years ago

Anyway, the format is pretty simple and there seems to be lots of ways to do the signing. The document is correct about the limitations of Zip. It might be time to create a new format.

Lennie commented 9 years ago

Sorry to bother, I don't know the use-case for packaging but:

Instead of a new format, why not make it transport agnostic ?

Why not sign the content instead of the package ?

If you sign the content, you can deliver it piece meal over HTTPS for example as well.

For example I believe the research project Mylar signs HTML.

An other idea would be to sign a manifest file (might not be very popular word anymore because of HTML5 offline support).

In the manifest file you can include: the hash of each file, which files don't need to be signed because they are dynamic (like offline support), a certificate and a signature.

Although my gut feeling is policy should be included in the HTML-file as a CSP-header in a meta http-equiv tag instead.

I know webappsec now has subresource Integrity, but not having to refer to a hash in every HTML-file might be easier, so a manifest file could still be useful.

It's just some thoughts.

tanx commented 8 years ago

I'm not sure if I created a duplicate in https://github.com/w3ctag/packaging-on-the-web/issues/29 or if this issue is broader than just signatures and key continuity.