- From: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
- Date: Wed, 22 Aug 2012 14:06:27 -0600
- To: Ryan Sleevi <sleevi@google.com>
- CC: Mountie Lee <mountie.lee@mw2.or.kr>, Web Cryptography Working Group <public-webcrypto@w3.org>
- Message-ID: <CC5A967C.5603%s.durbha@cablelabs.com>
Ryan Thanks for opening an issue related to this. We can use it to track the conversations. I think that depending on how restrictive or flexible (and regardless) our origin-bound policy is going to be, it is imaginable that applications may want a slightly different interpretation or result. Today, browsers allow the (server) applications to set this policy for cookies – and I think we can extend the same feature to keys. Seetharama On 8/22/12 11:25 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote: On Wed, Aug 22, 2012 at 8:30 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote: On 8/21/12 7:33 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote: I've been trying to find a way to propose text that balances these concerns, but to be honest, I don't have a good solution. Part of this is what lead to the proposal of requiring CSP, since this can mitigate (some of) the security concerns, but I think there's still a lot of security risks that have to be talked through and discussed before we go too far. Ryan, >From my notes at the F2F, we had attributes of type scope (including access control and temporary/permanent). These were supposed to be set at the time of creation and read-only after that. Access control attribute was meant to allow the origin to specify which sites can access/use this key (may be we need granularity of purpose too). My notes on access control had it related to key usage. I have not been following the conversations much lately, but I do not see the access control attribute in the draft (temporary is there). Has it been dropped because of some reason? To the extent it's been discussed on the list, there seems to be opposition to granting multiple origins access to a key. See Mark and Mitch's responses about wanting to have keys that are only available to a single origin, and what I read as general opposition to permitting key sharing. While David mentioned it as a possibility, there hasn't really been discussion on 1) What use cases it has 2) What the security implications are 3) What the behaviour should be 3a) Can it only be specified at creation or is it mutable at some later point 3b) The behaviour of pre-provisioned keys The usage of Web Intents offers one way for origins to "share" keys, and without undermining the fundamental properties of the key (eg: allowing Origin-B to spoof messages from/to Origin-A). I think it's something still reasonable to discuss if the WG wants to, but we should open another ISSUE to capture the requirements and need.
Received on Wednesday, 22 August 2012 20:06:54 UTC