- From: Chris Palmer <palmer@google.com>
- Date: Wed, 11 Jun 2014 10:34:59 -0700
- To: Mike West <mkwst@google.com>
- Cc: Zack Weinberg <zackw@cmu.edu>, Katharine Berry <katharine@getpebble.com>, Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 11, 2014 at 2:40 AM, Mike West <mkwst@google.com> wrote: > I'm not convinced that allowing a website's JS to "poke a certificate into > the browser" or "[suspending] normal PKI rules" is a better solution. Both > of those scare me. And scare you they should. :) > Basically, you're proposing changes to what the browser should do on the > transport-layer and how certificates should be minted and distributed. I > hesitate to send anyone to the CA/B forum, but I think that's where this > discussion might need to happen. I don't think so. I mean, I agree that the mechanisms of origin authentication are distinct from this mixed-content spec/definition, but I don't think a new discussion in the CABF will be fruitful for Katharine and people with her (interesting) use-case. I think we should continue in this forum to find a way to make Katharine's use case work without compromising security for users in general or for Pebble device hackers in general. Unfortunately, I don't happen to have a solution on-hand. :) But, I am also a weirdo who believes that installing a custom, local trust anchor is still easier than installing an SDK, and would hopefully not cross a user-friction threshold that would break the use-case. > Manually installing a certificate that Pebble provides seems like the right > solution for the TLS side of the problem. That was rejected as being too > much work for the developer. Personally, I'd prefer that we reevaluate that > objection. Exactly. We're talking about people who can write Pebble apps in JavaScript, right? So maybe they are newbie or casual developers, but still they went to the trouble to learn some JavaScript and some Pebble APIs.
Received on Thursday, 12 June 2014 09:30:26 UTC