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


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 06:34:17 UTC