Re: [WebCryptoAPI] + Signed JavaScript

On 2013-08-07 17:52, Thomas Kopp wrote:
> Dear all,
> This project seems to be very interesting and could solve a couple of problems. Enclosed, please find some questions:
> -          What is the status of the project? In particular, are the indicated planning and milestones still up-to-date?
> -          Which browser vendors will support the API? Any commitments yet?
> -          Will support also be available on mobile platforms?
> -          Important: This API exposes sensitive functionality that is supposed to be called via JavaScript. Unfortunately, JavaScript has no cross-platform support for using signed code only. As a consequence, this API risks to be a first class candidate for attackers, since it permits executing sensitive operations in potentially unsecure environments. Thus, it would be desirable that the same workgroup also covers code signing of JavaScript and proposes a cross-platform approach with recommendation to the API vendors for implementing it. This strategy would not only permit performing signature operations via JavaScript, but also to protect applications (and their users) employing such an approach.

Hi Thomas,

FWIW, I'm working (individually and entirely unsupported by the WebCrypto WG),
with a scheme that indeed relies on signed JavaScript.

However, it does not follow the traditional code-signing route because I don't see
that the question "Do you accept etc." adds any real security to the plot; it is
mainly just a nuisance (there is a lot of experience with for example Android
apps that request various permissions that a normal user haven't much clue about
what they mean and effectively requires you to "Trust" unknown code or hoping
that PlayStore have analyzed it properly).

In the devised scheme the required "Privilege Elevation" is limited to specific
keys (=trust-networks) which I believe matches the actual use-cases fairly well.
The logic behind this is that "Keys" and for example "Your Location" represent quite
different resources and therefore do not have to use the same security/trust model.
In addition, possible screw-ups are confined to specific trust-networks which
differs from existing signed Java and ActiveX plugins that lacks such granularity.

The true rationale behind this is though NOT adding security to WebCrypto (it probably
doesn't...), but "Bridging" the old (Established/TLS) and new (WebCrypto/SOP) worlds
with the goal creating a united platform for keys:

WebCrypto's current key generation model suffers from several shortcomings
(Google "indirectly" agrees:
It seems to me that it long-term would be smarter having a single facility for this purpose.

Anders Rundgren

Received on Thursday, 8 August 2013 07:43:00 UTC