Re: KeyStorage and Pre-provisioned Keys: A proposal

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.

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.

…Mark

On Nov 15, 2012, at 3:49 PM, Ryan Sleevi wrote:

> On Thu, Nov 15, 2012 at 3:18 PM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Nov 15, 2012, at 2:56 PM, Ryan Sleevi wrote:
>> 
>> Ryan,
>> 
>> I excepted one point from your mail as I feel it is important:
>> 
>>> Again, there's certainly a committment and interest in these issues.
>>> However, the feeling is that the most important and pressing issue is
>>> basic algorithm and usability support.
>> 
>> This may be *your* feeling, but it is not mine. The API is essentially useless to us without support for pre-provisioned keys and so they are just as important to us as any other part of the API. Something we've made clear from the outset of this work.
> 
> Mark,
> 
> (Hopefully) nothing in this spec prohibits you from implementing
> support for pre-provisioned keys on your own.
> 
> I would suggest you look at how other APIs have been specified - such
> as in WebApps or HTML WG - or proposed - such as in SysApps - to see
> how a number of other vendors and implementers are able to continue to
> make progress and improve the open web platform without requiring the
> "everything and the kitchen sink" approach to specs.
> 
> Indeed, it is not at all uncommon to see specifications broken up
> (see, for example, CSS Modules), and independently and concurrently
> developed.
> 
> I'm sympathetic to the need's of Netflix regarding pre-provisioned
> keys. I imagine you may equally feel that HTML is useless for Netflix
> without Encrypted Media Extensions, or that <video> is useless without
> the MediaSource APIs. However, it seems that both HTML and <video>
> have been able to progress and be useful for a number of other
> participants, without requiring that support, and I would suggest the
> same is here - a number of audiences and needs can be addressed
> without pre-provisioned keys, and so I do not think it useful nor
> considerate to those use cases to block any progress based on this
> specific issue.
> 
> We didn't have to land on the moon in order to say we discovered
> flight, nor do I think we need to solve everyone's use cases in the
> first release to have a meaningful API for the open web. Otherwise,
> we'll spend the next three years discussing certificate discovery,
> OCSP, and Kerberos APIs, and deliver nothing in the mean time.
>

Received on Friday, 16 November 2012 03:42:56 UTC