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

Re: KeyStorage and Pre-provisioned Keys: A proposal

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 16 Nov 2012 13:40:35 -0800
Message-ID: <CACvaWvZvC0G7iZfXj_E7mStteH46=1Mxd15uV-oGBaR+EFjQ4Q@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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." 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 Friday, 16 November 2012 21:41:03 UTC

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