- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 18 Sep 2012 14:10:04 +0200
- To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Wendy Seltzer <wseltzer@w3.org>
- Message-ID: <5058649C.5000807@w3.org>
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 >
Received on Tuesday, 18 September 2012 12:10:20 UTC