Re: W3C Web Crypto WG - Is our deliverable doomed ?

There are two ways I look at this

 1.  Just an API – no mention of trust of any kind
 2.  Some guarantee of trust

If we (can) limit our effort to just the first, it is a straight-forward exercise of creating a crypto API akin to crypto API in any language.

Question is 'will we be forced to answer the trust question?'. I think all of us have repeatedly acknowledged that there is no trust in any web client (unless the client itself has identity and uses secure protocols in turn). Thus, an application using JS API to generate/store any kind of keys in a browser, must acknowledge that those credentials are not secure, in fact can be shared openly without the server knowing about it. Trust for any application does not come from the browser a user uses, but from the user themselves. The application trusts that a user is wise enough to use the correct browser, enter their credentials in the right web site, and so on.

Question then becomes 'What is a right browser?'. We use browsers to access all kinds of sensitive data on the internet. I trust that the browser is not stashing that data in a server. (Frankly, such a behavior is easy to verify and control.) So, we already have a lot of trust in the browser. Is that trust not sufficient to handle keys? I think it is sufficient. (In an earlier email, I mentioned that for signatures, browsers need to provide that trust through visual clues to what data is being signed.)

So, to conclude – I think that trust is between the user and the server application. Browser is a best effort. This WG delivers the API and facilities browsers will provide to applications. Anything else is not this WG's concern.
(Again, in an earlier email, I mentioned that trust is also between the user and the browser – and that argument still remains.)

-Seetharama


On 9/18/12 6:10 AM, "Harry Halpin" <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:

On 09/18/2012 11:20 AM, GALINDO Virginie wrote:
Dear all,

Highlighting a link that Harry shared with us during the conf call yesterday. I think we should read that and try to see where we have been ‘better than expected’ for providing security for webapp. This would definitely help to better describe our value proposition, I think – and clearly know our limits ;-)
http://www.matasano.com/articles/javascript-cryptography/

I think requiring CSP plus having the API work natively on the client addresses rather than be downloaded his issues re hijacking and malleability of the Javascript runtime, although the latter point requires serious deliberation on our part. In particular, we will clearly address "the lack of systems programming primitives needed to implement crypto" and issues he brings up like "random number generation." Also, he assumes TLS is working just fine and should just be used rather than any JS crypto, which it may be if you are using pinning+cert transparency, but that is not always the case - and many of the things that we need this API for, like signatures, cannot be easily done within WebApps as TLS does not let these functions be accessed in an API.

It seems to me the rest of the arguments here can be repurposed against using cryptography any programming language, not just a Javascript run-time environment. Which basically would mean cryptography is in general doomed because its hard, yet given its usage and utility, this is self-evidently not the case. I'd like to hear the opinion of others

  cheers,
      harry



Regards,
Virginie