- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 7 May 2013 10:48:46 -0700
- To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
- Cc: Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Tue, May 7, 2013 at 8:14 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com> wrote: > With the ownership of the key based on SOP that is not cognizant of > tampering (as of now), I am afraid that any discussion of signatures will be > futile, they cannot be used for non-repudiation, at the end of the day. > > http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0247.html I don't see why you equate the discussion of ownership at all with tampering/proof. Further, I don't know if your claims are entirely justified to say "They cannot be used for non-repudiation". A quick example of the many attack vectors that exist in today's applications - and yet are still somehow acceptable for non-repudiation: 1) Native executables may or may not be code-signed. 2) There is no way for native executables to verify that they have been properly code-signed with no malicious code injected. If malicious code was injected, it would just lie. 3) There is no way for smart cards to know whether or not the calling application is "legitimate". For example, it's not at all uncommon to see malware hijack smart cards (eg: see Sykipot) There are two realities here - the technical reality and the political reality. The political reality of non-repudiation likes to believe that today's solutions are acceptable - even though the technical reality is flawed. If these arguments all sound familiar, well, it's because I said the exact same thing in September - see the thread http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0156.html (and don't forget Anders' comments on public-webcrypto-comments at http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Sep/0010.html ) This disconnect has nothing to do with the ownership model of the key - either you accept some technical realities or not. For example, in the native code, you have no assurances that hostile code/malware is not running on the users machine. A PIN or password do nothing to mitigate this threat. If you accept those signatures, then WebCrypto should be the same. Your "code signature" is handled via TLS - and your signature verification can be bolstered via means such as pinning. Either you trust that code or you don't - no different (nor more flawed) than native. I'm sympathetic for those who want "more" assurances - but I want to make sure it's recognized how fundamentally flawed the argument is when compared to the already deployed, politically accepted reality of general purpose computing. If we're going to try and improve things, we must set reasonable expectations about what the real threats are and what the benefits are. If the only security guarantees for the Web API can be realized when on a fully restricted, user-hostile machine (eg: not the general purpose machine that the browser vendors represented here develop for), then I'm more inclined to suggest that it belongs elsewhere - such as SysApps or somewhere else - because it doesn't reflect a general pattern for an open Web.
Received on Tuesday, 7 May 2013 17:49:14 UTC