- From: <bugzilla@jessica.w3.org>
- Date: Mon, 04 Aug 2014 15:33:26 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 --- Comment #24 from Harry Halpin <hhalpin@w3.org> --- The existence of extractable keys has some use cases that the Working Group has already gone over in detail. For example, backing up keys. Also, Ryan, Tom, and Elijah all agree that currently with the design of Javascript and Web Crypto, private keys can always be extracted by the server, even if the keys are marked unextractable. Does anyone have any text to put under the definition of "extractabie" (Currently just "Whether or not the raw keying material may be exported by the application") to help Web developers understand that keys marked unextractable may not actually give protection of private key material from the server? I think the question is what are the use cases for truly non-extractable keys that can't be accessed by the server, so the server has no actual way of decrypting the data. The obvious use-case is applications where there is to be genuine user-to-user (end-to-end encryption) where the server cannot retrieve the private keys (at least without the user's knowledge). Right now on the Web, the server that serves the code is *always* trusted (Trent) as it can modify the code it wants, and thus always modify the code to get the keys. So Ryan is right, this is basically impossible. My observation is that while there are valid use-cases for user-to-user (end-to-end) encryption, Ryan is right insofar as it seems impossible to build these types of applications on the Web. However, it would seem possibly desirable in the future for the Web to support such use-cases. Thus, we are hoping that broaching this topic with the wider WebAppSec group at W3C, and perhaps later with the relevant other standards bodies, would be at least a start. Would this satisfy the reviewers? (In reply to Tom Lowenthal from comment #23) > Ryan, I chose my words carefully. I said “trustworthy” not “secure”. I think > that the option of extractable keys makes it harder for applications built > on this API to be worthy of users' trust. > > As you say — if someone wants to make a key which they can extract, they can > do that right now. My objection is based on the firm belief that the ability > to extract keys is a harmful design pattern. I think that this choice would > give developers enough rope to shoot themselves in the foot which would be > harmful to web security. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Monday, 4 August 2014 15:33:28 UTC