W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: Rethinking KeyStorage

From: Mark Watson <watsonm@netflix.com>
Date: Sun, 4 Nov 2012 03:27:25 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>, Arun Ranganathan <arun@mozilla.com>
Message-ID: <8D0FFFD3-7310-446B-94B9-A510F445F699@netflix.com>

Sent from my iPhone

On Nov 3, 2012, at 1:59 PM, "Ryan Sleevi" <sleevi@google.com> wrote:

> On Thu, Nov 1, 2012 at 8:21 AM, Mark Watson <watsonm@netflix.com> wrote:
>> Ryan, all,
>> I'm sorry I missed the discussion of this. Can you explain how the application would find the Key object for a pre-provisioned key in the proposed new model ? It's clear how this is done with KeyStorage, so if you're going to remove KeyStorage we need a solution in the new model too.
>> ůMark
> This proposal currently treats pre-provisioned keys as "out of scope"
> - which is to say, it says nothing for nor against them, nor how they
> may be implemented or exposed by a particular user agent.
> Given that pre-provisioned keys are a concept that, to some extent,
> have significant privacy concerns - in addition to being
> implementation-specific - this seems a reasonable balance between
> ensuring that the primary features and goals (as specified by the
> charter) are met

Pre-provisioned origin-specific keys are very much a primary feature, as far as I am concerned, as we have made clear from the very beginning of this work.

I understand from our conversation that your proposal would support them and I think the specification needs to say how.


> , while equally being considerate and not actively
> forbidding features that can be further developed and standardized in
> a subsequent version of the document - particularly one that embraces
> the secondary feature of "multiple key containers", which I would
> suggest that keys not explicitly generated by an origin logically fall
> under.
Received on Sunday, 4 November 2012 03:27:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC