- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 24 Sep 2014 14:05:14 +0200
- To: public-webappsec@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Forwarded Message -------- Subject: Verified Javascript for WebAppSec re-chartering? Resent-Date: Wed, 24 Sep 2014 12:02:09 +0000 Resent-From: public-web-security@w3.org Date: Wed, 24 Sep 2014 14:01:54 +0200 From: Harry Halpin <hhalpin@w3.org> To: public-web-security@w3.org, benl@google.com [cross posting to Web Security IG, cc'ing Ben Laurie] An interesting use-case has come up in the Last Call for the Web Cryptography API which the Web Crypto API cannot fulfil without further changes in the Web Security Model [1]. I'll illustrate the use-case, although I may not do it justice so I recommend that people read the full discussion on Bugzilla [1]. Currently, the Web Cryptography API allows keys to be either extractable or not. The commenters have request that extractable keys be disabled by default and activated only with some "Trusted UI" interaction, since it seems that it would violate a user's expectation that their private key material be sent back to the server, although there are of course protocols that do this. It was also pointed out that since the server at the origin can change the JS at any time, they could change the JS so that it generated a new extractable key and used that key for whatever cryptographic operation was desired at anytime. In other words, the main problem is the user has no assurance or attestation that their Javascript code in general and their key material in particular is being used in the manner they were hoping it would. However, it is unclear how to do this today. In general, from a cryptographic standpoint, on the Web if one is trying to do any form of trusted end-to-end communication between two users (say Alice and Bob), the web server that mediates their communication is always completely trusted (Trent). This would seem to disable an entire class of applications are then not really suitable for the Web, i.e. those applications where the server may not be trusted. In that case, it seems that having some third party verification of Javascript code would be useful. This may also be useful for Web applications where the server is trusted but may be insecure. It seems Sub-resource integrity is headed in this direction, but we can also imagine other ways this may be tackled that involve some third party verification of Javascript. I believe Ben Laurie noted that in his STRINT submission some CertTrans-like mechanism could even be used [2]. Without this, we see developments like Chrome's e2e email extension as browser extension rather than being done natively in the browser. It seems that future development on the Web will require some level of third-party attestation and assurances of both Javascript code (as done in package managers today) as well as more secure key storage (as falls within the remit of the Web Cryptography API re-chartering). Thus, to respond to Tom Lowenthal and Elijah Sparrow, I'd like the Bugzilla comment on the Web Cryptography API to fall within the scope of possible future work items for the new charters of the Web Application Security and Web Cryptography API. [1]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 [2]https://www.w3.org/2014/strint/papers/15.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJUIrN6AAoJEPgwUoSfMzqcnfEQAJOpQLXyiKgzk+YVowbISWLr ZZFXSntHbbrW8zmBt8IjtUXg5x7pYoYwC0mIPVzovxyRusE/JsuAUjk+iLNWWbC/ j+MOAVcA4URhop7vQfxaI0btC1kH0tg/hF407fPcK3SfOJu6bqMCDc5XANcqEelG MA9GRbdwf+yNjEBE4GIkgQVdV0QpvHAFBMe2XyiWCsLEbhevn/Ppu5civ5vjYn1d rZ+ubCYyiU6FAPxFiw80XCETusN5VVuLzRr5WA+fh74eIg1aIbUexGxiFimeS6NF KCYt0aRMxx+3aShEQKU2rJ1HQriYZ+mD+JDaNA8fejv5h8nBOP6OW7vrEV5O2KmF hfMe4JloTsmhUywq+yPv4bA1fKKOTZYJZdlwkQQT4SzRxFllIMWND6hsTuZRIqLL ZUGF5IyI2EGeGFpOgEk6V+4PlaCxqYF6Hoc2hRScLI5SfRQjEZP9v3snCxztKPkf YdX5iBuk65gFf+lvuFmoUAe8aBwZHbAAzcPoHDAOSvraYqixrmPL8p3+/dAMEg8A eEpT3sZrrzpBqCCx4ls7q9Q/N9dqpRfBTF8d1MPaArwroHKlX+gZ9bPrtqqVRlgk M+EuIUrjOyy+e4RFQ2XfVQ/uzdOqaRF7WYT1R7bP5NzUVqi0DZRo3r1SA9Elz4T5 g+yv6NLPuczTgtgoiRS2 =L5oD -----END PGP SIGNATURE-----
Received on Wednesday, 24 September 2014 12:05:22 UTC