W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

Re: Usefulness of WebCrypto API - proposal to move forward

From: David Dahl <ddahl@mozilla.com>
Date: Fri, 12 Oct 2012 16:45:03 -0500
Message-ID: <50788F5F.1010606@mozilla.com>
To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
CC: Mountie Lee <mountie.lee@mw2.or.kr>, Ryan Sleevi <sleevi@google.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Harry Halpin <hhalpin@w3.org>, David Rogers <david.rogers@copperhorses.com>, Nadim Kobeissi <nadim@nadim.cc>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>

Hash: SHA1

On 10/12/2012 02:55 PM, GALINDO Virginie wrote:
> Dear all,
> >From the different exchanges held on this mailing list, I think that
we do have a structure for enriching our security considerations about
the API. I think that we can write a WG position - as suggested by Vijay
- with all the details and rationale, make sure we all agree and
consider putting this (or a summary) in the specification itself.
> I would suggest the following outline :
> 1- Considerations on 'local resources' (I mean UA and OS) security
> 2- Considerations on server-webapp communication security
> 3- Considerations on the benefit brought by the API (e.g. functional
and interoperability)
> 4- Recommendation to developers to establish a trusted environment to
complete their security model (like : audit the platform (UA+OS), use
CSP, use TLS, signature, ...)
> We discussed during our last call that David D would write something
about security and environment : David would you like to expand this
outline ?
> Anyone else to support this work ?

Indeed, and the week has gotten away from me, however, this is what I
wanted to propose we begin the section "Security Considerations" in the
API draft:

- ---

With the understanding that the web browser DOM is a perilous place
fraught with multiple attack surfaces, the point of creating this API is
not to solve these "generally insecure JS/DOMWindow context" problems.
The point is to design a crypto API that can theoretically be used to
fulfill the use cases the Web Crypto API WG has drafted.

While this API is not recommended for use in content DOM web pages,
there are DOM environments that can more securely host this API.
('Privileged' and 'Certified') Open WebApps ( see:
https://developer.mozilla.org/en-US/docs/Apps ), like those being
created for Firefox and Firefox OS enable a restricted environment where
the apps are cryptographically signed (and then verified upon install or
update) remote resources are quite limited, explicitly-granted
permissions are required, eval() and additional JS and browser features
are disabled, making the DOM a much more 'trusted' environment to
operate in. ( see:
https://wiki.mozilla.org/Apps/Security#Installed_privileged_application )

Web browser extensions are also a potential consumer of this API, as the
extension APIs and SDKs of modern web browsers are arguably more secure
contexts for code like this to run in.

- ---

I have already discussed this concept somewhat with Ryan and others on
the mailing list, with Ryan concluding that these environments are not
any more secure than a web page with strict CSP and HTTPS enabled, I
have re-read the Open WebApps security model (for 'privileged' and
'certified' apps) remembering that the eval attack surface is gone as
well as a very strict CSP is in place. These restrictions along with a
signed, installed zip-based application do seem to me to be a leap
forward in securing and being able to trust the web app.

Thoughts? Edits?



Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

Received on Friday, 12 October 2012 21:45:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 October 2012 21:45:35 GMT