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

Usefulness of WebCrypto API

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Mon, 8 Oct 2012 19:22:24 +0000
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
CC: David Dahl <ddahl@mozilla.com>, Emily Stark <estark@mit.edu>, "Wan-Teh Chang" <wtc@google.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, 'Harry Halpin' <hhalpin@w3.org>, Ryan Sleevi <sleevi@google.com>
Message-ID: <382AD43736BB12439240773F68E90773BA114E@DF-M14-23.exchange.corp.microsoft.com>
  Then, what threat model does crypto in JA make sense for at all? Obviously, when there's some lack of trust on the server *or* connection to the server that can be ameliorated by public key crypto.

Harry asked the above on a different email thread. This is an important question. But first we should be precise about what we're asking. WebCrypto is not (only) about "crypto in JS". It is about giving JS access to the crypto capabilities of the underlying platform. This includes cases in which the actual crypto is done elsewhere such as in a smart card.

So when does it make sense to give JS access to the platform's crypto capabilities? In my mind, there are a few possible answers.

It makes sense when one wants a trusted piece of JS in a trusted UA to interact with a less trusted data store. This is the Facebook use case. It is also David's cloud storage use case if the script is retrieved from somewhere other than the server that keeps the data.

It makes sense when one wants a trusted piece of JS in a trusted UA to be able to interoperate with a server using an existing protocol (e.g. sign requests to access-controlled REST APIs, JimD's use cases on authenticating to government services).

It makes sense when a server wants to deliver JS that uses a trusted piece of pre-provisioned crypto hardware to establish end-to-end trust independent of the UA (e.g. using a smart dongle for online banking, some of the Netflix use cases).

There may be others, and I'd love to hear what others think.

It's important to note that the "trusted UA" assumption is not as outlandish as it might seem at first; as Ryan points out on other threads, we routinely make an assumption that the OS is trusted when talking about native apps. One does not argue that including crypto APIs in operating systems is futile just because malware and rootkits exist. Many methods exist to improve the trust in the UA, including the use of non-browser JS implementations. One could also argue that various crypto primitives - notably hash and RNG - are only meaningful if one accepts this assumption.

Since this question seems to keep coming up in feedback, maybe we should develop a position on it as a group. Does anyone else have any thoughts on the matter?
Received on Monday, 8 October 2012 19:23:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 October 2012 19:23:45 GMT