- 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