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

Re: Rethinking KeyStorage

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 7 Nov 2012 10:24:33 -0800
Message-ID: <CACvaWva1uh+vZR=xRxZndUXOXCkRy5rEYTyF8LkgqjtTewYv9Q@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: David Dahl <ddahl@mozilla.com>, public-webcrypto <public-webcrypto@w3.org>, Arun Ranganathan <arun@mozilla.com>, Harry Halpin <hhalpin@w3.org>
On Wed, Nov 7, 2012 at 10:14 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 7, 2012, at 9:51 AM, Ryan Sleevi wrote:
>
>> Mark,
>>
>> Regardless of how attractive the current text is, I think that when
>> talking about what the deliverables are for the first version,
>> specifying features which either cannot or will not be implemented by
>> desktop or mobile browsers should be a serious warning sign as to
>> whether such things belong in the spec.
>
> I don't see any reason why pre-provisioned symmetric keys could not be implemented on either desktop of mobile browsers. Such things already exist in both these contexts.
>
> I strongly disagree with the idea that features that may not be implemented in the short-term on all devices should be excluded on that basis alone. It should be sufficient that there is interest in implementing a feature on one or move device types with significant volume.
>
> As the Web & TV Interest Group has identified, TVs and similar devices are different in several ways from desktop and laptop computers. If we have an ambition to extend the web platform to those devices (and I hope we all share that), then we have to stop using desktop browser implementation as the sole arbiter of commercial interest or source of implementation experience. There are 100s of millions of TVs and STBs using web technologies today and that figure is increasing rapidly.
>
>>
>> Regardless of how willing authors are to write spec text, or how
>> available existing spec text is, if it's notably bad for the web
>> platform in terms of design and semantics, or is categorically
>> problematic to implement for the open web platform, then it really
>> should not belong in the main spec.
>
> Neither of those criteria apply here.

If you believe this, I encourage you to look at the discussions
regarding Web Storage and see why this is very much the case.

>
>>
>> While I understand a read-only KeyStorage is attractive for your
>> specific business needs, the semantics are not good, and even if
>> they're something that individually we're unlikely to implement
>> (read-only or not), the semantics are enough of a concern that they
>> should be removed from the spec on design and aesthetic reasons
>
> I'm fine for KeyStorage to be removed on these grounds IF there is a better alternative that maintains functionality.

The onus when removing features that are demonstrably bad (see above)
should not be that a counter-proposal be provided. It should be
removed. If there is a proposal that can address the needs and be
agreed upon within the work group as something to incorporate (and
that will be implemented - which is very much a criteria for this API
as spelled out in the charter), then we can revisit.

However, bad features should be removed. Not kept simply because no
one has proposed something better.

>
>> alone
>> - not to mention all of the privacy reasons expressed elsewhere.
>
> The privacy issues mandates that we are open and transparent - being opaque, leaving silent loopholes for pre-provisioned keys, does not enhance users' control of their privacy.
>
>>
>> Again, I feel very strongly that we absolutely should not be
>> introducing optional features into the first deliverable.
>
> We have no choice about that, as you've pointed out regarding algorithms. With this as with algorithms we are not making choices: we are just reflecting in the API the empirical fact that there exist devices with varying capabilities in the world.
>
>> It is much
>> better for the web developer community - let alone implementors and
>> observers of the web crypto work - to instead focus on features that
>> can be universally agreed upon and implemented before spending effort
>> focusing too hard on the ancillary features needed by a few members -
>> whether they be certificate discovery, pre-provisioned keys, kerberos
>> APIS, or other.
>
> If there are people willing to do the work, it is actually much more efficient to let them do that than to divert so much effort into arguing that they should not.
>
> ůMark
>
>>
>> On Mon, Nov 5, 2012 at 12:35 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> Hi Ryan,
>>>
>>> I don't think we could agree to the removal of KeyStorage unless you're replacing it with something equally functional. I like the idea of using existing web storage mechanisms, but if there is no solution for exposing pre-provisioned symmetric keys, then it's not going to fly.
>>>
>>> Given your comments below, I think the best compromise would be to make KeyStorage read-only as I suggested below, and to specify the structured clone algorithm so that other storage can be used for other kinds of keys.
>>>
>>> ůMark
>>>
>>> On Nov 5, 2012, at 12:24 PM, Ryan Sleevi wrote:
>>>
>>>> On Mon, Nov 5, 2012 at 11:44 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>>>
>>>>> On Nov 5, 2012, at 8:59 AM, David Dahl wrote:
>>>>>
>>>>>>>
>>>>>> Perhaps, as the result of such experimentation, we could link to an "Editor's Note" in the spec that explains how a set of pre-provisioned keys might be implemented? This is something of a half-measure, (and speaking out of ignorance) but I understand that this is sometimes done in the case of features that the spec does not include, but some implementations find necessary.
>>>>>
>>>>> We have a great deal of implementation experience already with pre-provisioned keys and it was a requirement that we raised at the very first workshop which lead to this group, so I think it's reasonable to continue to consider them in-scope so long as there is a use-case, proponents and people prepared to do the specification work.
>>>>
>>>> No matter how prepared people are to do the specification work, I
>>>> think we should be more concerned with people prepared to do the
>>>> implementation work. It's very clear from our face to face, and from
>>>> comments you made, that there are some features that are not desired
>>>> nor planned to be implemented by all user agents. I strongly believe
>>>> that those features should be omitted from the first version of the
>>>> spec, and should be moved either to a supporting document (profiling
>>>> the API for a particular set of use cases) or postponed for a separate
>>>> and optional document, rather than being introduced into the primary
>>>> document.
>>>>
>>>>>
>>>>> I have no problem using existing web storage mechanisms for storing Key objects. This seems very reasonable.
>>>>>
>>>>> I am only asking that the means by which pre-provisioned origin-specific Key objects are exposed be clear in the specification after this change is made, just as it is clear now with the KeyStorage object. The re-use of existing key storage mechanisms is one thing, the support for pre-provisioned keys is another. When you change the first you should not 'accidentally' remove the second.
>>>>>
>>>>> If it is reasonable, from an API definition and implementation perspective, for pre-provisoned origin-specific Key objects to appear 'automatically' in IndexedDB or whatever other storage API is available, then this is fine. This could indeed be mentioned in an informative note.
>>>>
>>>> I would strongly object to such a note being added to the primary
>>>> spec. The whole point of removing KeyStorage is to specifically avoid
>>>> needing to mandate any particular storage type for Keys. I feel like
>>>> recommending IndexedDB in a particular scheme, beyond crossing over
>>>> into land that might be better co-ordinated with WebApps, sort of
>>>> defeats that goal/concern.
>>>>
>>>>>
>>>>> Another possibility would be to retain the "keys" array as a read-only list of pre-provisioned origin-specific Key objects (so Key objects could be retrieved but not stored here).
>>>>>
>>>>> Regarding schedule concern, the best approach is to drop features where there is low support or an absence of people prepared to do the specification work.
>>>>
>>>> There are two very different types of support - support as "that would
>>>> be nice" - which is very easy to for people to express positive
>>>> feelings towards, like moms and apple pie - and support in the sense
>>>> of "This will be implemented (and in line/in time with the chartered
>>>> schedule)".
>>>>
>>>> The more "informative but not implemented" features incorporated into
>>>> a spec, regardless of how valuable or nice, the worse the spec
>>>> becomes. Equally, each supplementary-but-not-essential feature
>>>> increases the time for review and, particularly if the feature is
>>>> controversial (such as on grounds of privacy), the greater the chance
>>>> of Formal Objection being raised for a feature that is otherwise
>>>> possible with the existing API.
>>>>
>>>> The Spec does not and should not be required to list or enumerate,
>>>> normatively or informatively, how certain solutions would prefer to be
>>>> implemented. As long as the spec permits the desired operations, which
>>>> I believe it does, I feel we're better off as a WG to postpone the
>>>> detailed discussions until the basics are in place.
>>>>
>>>
>>
>
Received on Wednesday, 7 November 2012 18:25:09 UTC

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