Re: Rethinking KeyStorage

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.

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.

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 alone
- not to mention all of the privacy reasons expressed elsewhere.

Again, I feel very strongly that we absolutely should not be
introducing optional features into the first deliverable. 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.

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 17:51:36 UTC