- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Jun 2014 21:00:40 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 --- Comment #5 from Ryan Sleevi <sleevi@google.com> --- (In reply to Boris Zbarsky from comment #4) > Ryan, the issue with just telling implementations to do whatever they want > is that you don't get to interop that way. So I think we _do_ want to > define exactly where this API is available. The spec already says that. There are zero mandatory algorithms. > > My personal preference is that it's available everywhere; I haven't seen > particularly good arguments against doing that, honestly. But just having > the spec explicitly say that the API can either work or not, completely > randomly from the point of view of authors, is really not OK. There is no way to build a secure system on an insecure transport. Even the 'best case' example, provided by Netflix, requires bootstrapping trust either using a UA-specific means (named key discovery, among others), or first bootstrapping on TLS. Even when bootstrapped over TLS, the resultant API provides no meaningful security guarantees for the user - it's just an authentication mechanism. Unlike exposing low-level cryptographic primitives, which CAN be combined into ways that grant REAL security (eg: the combination of CBC+HMAC+random IV in EtM, ala the mcgrew AEAD), this is something which CAN NOT be used to provide meaningful security in isolation. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Wednesday, 4 June 2014 21:00:42 UTC