Re: KeyStorage and Pre-provisioned Keys: A proposal

On Nov 16, 2012, at 1:40 PM, Ryan Sleevi wrote:

> On Thu, Nov 15, 2012 at 7:42 PM, Mark Watson <watsonm@netflix.com> wrote:
>> Hi Ryan,
>> 
>> I understand the points you make below. Indeed we have been using web technologies and pre-provisioned origin-specific keys on TVs and like devices for several years. We feel we have done a lot of experimentation already. That was one reason we thought this was ready for standardization when we brought it to W3C a year and a half ago.
>> 
>> I think where we differ is that you seem to think pre-provisioned keys are 'landing on the moon' or 'everything and the kitchen sink', whereas I don't see them as more significant than including or not some given crypto algorithm. The first version of the specification will include those algorithms that WG members propose, prototype, plan to implement etc. and will not include those that WG members don't propose etc. The same should be true of mechanisms to get Key objects in the first place.
>> 
>> We have a solid key-source-independent API in the Key object. Providing various ways of obtaining Key objects (generation algorithms, raw key import for various kinds of keys, various unwrapping algorithms, pre-provisoned, ..) is just a question of what people are prepared to work on specifying.
>> 
>> Regarding implementation and experimentation with the WebCrypto API itself (rather than similar functional approaches that I refer to above), this isn't going to happen on TVs and like devices without some guidance from W3C. These are not desktop browsers where the implementors themselves are at W3C meetings and experimental features can be shipped behind compile-time or runtime flags. If the W3C has any ambition to extend the web platform beyond desktop browsers (and I think it should and I believe through the existence of the Web & TV Interest Group and other activities that it does), then this must be taken into account. The early stages of the specification process are exactly the place to do this, by including features for which there is demand and implementation interest and effectively "calling for implementations" through the specification advancement process.
> 
> While I certainly respect and understand this position, I suspect this
> highlights are fundamental differences on what we'd like to see as a
> first version / candidate recommendation. Certainly, some working
> groups have gone that approach - but I think their charters and timing
> have reflected their forward-thinking, optimistic, "if we spec it,
> they will come" approach.
> 
> Certainly, that's not a view I share, nor do I think is reflected in
> the chartering timeline. I suspect that, had we realized this
> disconnect in views, we would have made this position especially clear
> during chartering.
> 
> While I certainly can't speak for other members, our interest is much
> more in the "This is what we're implementing/have implemented/have
> experience with, and we think/have demonstrated it has value for the
> web and browser community and ecosystem."

Well, then, we're closer than you think. If you accept that the first "This" in that sentence might be different for different parties, and if you include TVs and Set Top Boxes using web technology in the "web ecosystem", then I'm happy to sign up to the same statement with respect to pre-provisioned keys. That's consistent with what I said above. What I think is unlikely is that you would get multiple or the major TV manufacturers turning up now saying that they plan to ship this in the first half of next year. So I would object to that being a pre-condition to even discussing the technical solutions, as you seem to suggest. By contrast I think we have multiple desktop browser implementors expressing interest in shipping some other parts of the API relatively soon. I'm saying you should not hold TVs, with year long development cycles, to the same standard as browsers working to two-week sprints.

…Mark


> Such an approach focuses on
> incremental improvements and expansions of scope, as implementors
> continue to address the needs of their users, - much like FileAPI,
> much like Web Storage, IndexedDB, and several others.
> 
>> 
>> So, again, what I suggest we do is discuss technical options for replacing KeyStorage with a better way for obtaining pre-provisioned (or other kinds of) keys. Treating this capability just as we treat algorithms seems quite an attractive way forward - those cases we can solve in time will make it into the first version and those we can't will not (just like the situation with other kinds of algorithm). You don't like overloading import (though I don't think it's that bad) so perhaps we should try a "retrieve" or "import external" method ? Can we at least have a technical discussion on that topic ? At least if we did we would then have concrete proposals to discuss.
> 
> I disagree with the suggestion that this is, at all, comparable to
> algorithms. Nor do I think algorithms is entirely a great model - a
> point I have repeatedly stressed is an unfortunate necessity of
> optionality, rather than being an actual guarantee of an API.
> 
> I've already provided several areas of technical feedback, as well as
> a proposal for a way forward. As both an author and an editor, I do
> not feel any personal imperative to design a feature for Netflix's
> case - or that for any other specific member. My goal as editor is
> simply to ensure the functionality is consistent with the overall work
> and that it reflects the overall consensus within the group, my goal
> as author is to contribute based on implementation experience and
> overall goals, and my goal as an individual member is to ensure that
> collectively, the API is both usable and relevant to the web developer
> community.
> 
> I think Netflix is certainly welcome to make proposals that can
> address their needs, as can any other member. And like all features,
> it becomes a matter of building consensus within the work group - that
> this feature is something that MUST be included in the first version,
> that this is how it SHOULD be implemented, and any other
> implementation concerns based on past experience, goals for the web
> platform, or, as time develops, future work.
> 
> Rather than using the spec as a "This is what we think works, hey
> implementors, tell us if it does", I'm a strong believer that this is
> better served by proposing work, perhaps as a separate document,
> implementing, and providing feedback about whether and how this should
> be integrated overall. I don't think that merely proposing text should
> be the barrier for entry into the spec, if only because I think it
> significantly misleads both developers and members - much like,
> apparently, the inclusion of KeyStorage seems to have lead Netflix to
> some conclusions about the API and implementation that were not at all
> intentional.
>

Received on Saturday, 17 November 2012 01:36:25 UTC