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

RE: KeyStorage and Pre-provisioned Keys: A proposal

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Mon, 19 Nov 2012 22:13:53 +0000
To: Mark Watson <watsonm@netflix.com>, Ryan Sleevi <sleevi@google.com>, "John Simmons" <johnsim@microsoft.com>
CC: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <4E1F6AAD24975D4BA5B1680429673943668D75F4@TK5EX14MBXC283.redmond.corp.microsoft.com>
I wanted to reinforce that John's note reflects a position that has been widely reviewed and vetted within Microsoft, including by IE.  (We were slow to respond to this thread exactly because it was being internally discussed and vetted.)

We believe that, per the issue resolution at the F2F, the editors should work with Netflix and others to incorporate API support for using pre-provisioned keys in a way that employs the principles of privacy by design.  We believe that this API support will be useful both for special-purpose platforms such as TVs/set-top-boxes/entertainment devices and for the open web.

I would have discussed this on the call today, were there one.  We can plan on discussing this on the next call.

				Best wishes,
				-- Mike

-----Original Message-----
From: John Simmons [mailto:johnsim@microsoft.com] 
Sent: Sunday, November 18, 2012 10:32 PM
To: Mark Watson; Ryan Sleevi
Cc: Harry Halpin; public-webcrypto@w3.org
Subject: RE: KeyStorage and Pre-provisioned Keys: A proposal

This is a very important topic and one which requires a very thoughtful discussion. 

We share the concerns expressed by both Google and Netflix regarding privacy. Code coming from a different origin than the pre-provisioned key will run in the origin of the site, so any resolution needs to address that concern.

Yet we share Netflix and CableLabs' contention that this is an important feature for the Web Crypto API to include. Support for pre-provisioned, origin-specific keys such as those which exist today on devices such as TVs and Set Top Boxes, when provided to scripts from the associated origin, with full user knowledge and consent, will enable scenarios which will be valued by those users. 

An explicit goal of the Web Crypto work is to support JavaScript as a programming language - not just for the open web. It is important to examine the browser/open web scenarios to determine how privacy concerns can be mitigated, but a thoughtful resolution of this issue cannot be achieved by examining the open web concerns, alone.

Pre-provisioned keys are commonly used today and they are often more secure than the alternatives. It is Microsoft's view that access to pre-provisioned keys should be supported in the Web Crypto API and that appropriate guidance on privacy considerations should also be provided.


It was our understanding that the issue resolution from the Lyon meeting was for the editors to work with Mark Watson on concrete text for pre-provisioned keys to be incorporated into the specs. We believe that this dialog should be redirected towards completion of that goal and the development of concrete text on how pre-provisioned keys are best accommodated within the Web Crypto API, creating a solution that mitigates open web privacy concerns. We are eager to help contribute to that effort.


John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911  | mobile 425-269-5759

> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Friday, November 16, 2012 5:36 PM
> To: Ryan Sleevi
> Cc: Harry Halpin; public-webcrypto@w3.org
> Subject: 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 Monday, 19 November 2012 22:14:51 UTC

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