Re: Rethinking KeyStorage

On Sat, Nov 3, 2012 at 8:27 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> 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.
>

As I mentioned, they're only out-of-scope in as much as they're not
defined how they behave, but they're not at all prevented from
working. As presented during the face to face, and as previously
iterated through other WGs such as WebApps, there is a strong desire
to not introduce yet-another-storage-mechanism to the web platform.
Making use of structured clone algorithm permits - but does not
require in any way, shape, or form - keys to be stored in the existing
web storage systems, and serves as the proposed resolution.

Given that our success criteria looks for solutions that has all
primary features implemented by multiple user agents, it as important
to consider what features are completely unworkable for implementors
as it is to consider what features a particular use case needs.

If there exists a counter-proposal to bring that can meet the needs
both of your individual use case and can avoid the areas of concern,
I'm sure the group would be very interested. I should note
individually, there is a strong belief that the solution will not and
should not rest in the introduction of further "optional" features
that will confuse or mislead developers.

I should also note that the current spec does not say how other
systems of platform-specific keys should behave, which is equally a
vital requirement for the use case of other participants. I think that
pre-provisioned keys are in fact more akin to such platform keys than
they are to web page keys. My position is that any discussion of
pre-provisioned keys must necessary entail support for, or minimally
discussion of, other types of keys (smart cards, OS keys, etc), which
entails the broader discussion of key discovery. Since such
discussions have been shown to be complex across multiple angles, and
in particular user privacy, I think it would be more fruitful to the
schedule to postpone such discussions until our next version.

I should note that postponing would also provide Netflix and other
implementers the opportunity to experiment with various approaches to
the problem, and will likely lead to a better, more implementable
solution than if this WG were to attempt to spec something up front
that may not be implemented for quite some time.

I am not trying to dismiss the Netflix case, but am intimately aware
of the concerns of attempting to meet our charter timeline -
http://www.w3.org/2011/11/webcryptography-charter.html . As mentioned
in http://www.w3.org/2011/11/webcryptography-charter.html#scope , API
features that are not implemented due to time-constraints can easily
be put forward in a roadmap document.

Received on Sunday, 4 November 2012 06:44:44 UTC