W3C home > Mailing lists > Public > public-web-security@w3.org > September 2014

Verified Javascript for WebAppSec re-chartering?

From: Harry Halpin <hhalpin@w3.org>
Date: Wed, 24 Sep 2014 14:01:54 +0200
Message-ID: <5422B2B2.90805@w3.org>
To: public-webappsec-request@w3.org, public-web-security@w3.org, benl@google.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[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)

iQIcBAEBAgAGBQJUIrKyAAoJEPgwUoSfMzqc+BgP/0dWqFJHnEs8C4vUPq7J8dhN
1IYSH+eTwnZ/ClqE1IQPFk93cja+psIvx182YdZbAmonZPLFTMhOs1Sl4p74E8JU
taR2i2ycQaPShzPNAOTsuAn1pqvUpiu48knsZEfo6Wh7M25QJ0m04wBjCvpmwL/b
gcliK6RHqKWhez+D54KDBl2PCuCBXFQ/d2bYm+cYa/PznNWpUxiCUfGktCusby/L
37uydu28AU3RW+GEeWx6hJLnv6YlBCd3Ojl2wDzcLf8LXZ6X+oNem6yFApfRSvUC
xM44WPmRg47RJxbCSqKNV+pnage5CVgkKHAYTBGwMZ87vH/d9IsM9SJ6b8IVd/CR
Rem6VTy6sRQD8pCts+C664izBby2Mn0ll/oK9czqirDmZuiHakhH2PEot47GaaL+
u5+eWyhvY15YoxqgkkQUEJU8pousbauD1BOf6aF8fFDResyfY1isP+F9skczqVLE
EYJvS8q5N10OAGwzr/SVbFyk8WzstrPNd4lydeM4LXVwscFt3vJUV3vQmjInbdY9
Ws6YKerL3Vtmw1rtj9IRRoWQCj9Op5WE0dXTA5czPO99arKEO33o3Y4vYxFL2bTu
a5LSSluTLG/+/d/vcDqZZWAvorVm6zup3HQWgKAZFFVj83UN+TeMnufbaDzJd+IR
6JSdH28tpO4ioDGenxB3
=VGNf
-----END PGP SIGNATURE-----
Received on Wednesday, 24 September 2014 12:02:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:32 UTC