Re: KeyStorage and Pre-provisioned Keys: A proposal

On Thu, Nov 15, 2012 at 2:14 AM, Harry Halpin <hhalpin@w3.org> wrote:
> On 11/13/2012 06:10 PM, Mark Watson wrote:
>>
>> On Nov 13, 2012, at 2:33 AM, Harry Halpin wrote:
>>
>>> I've been thinking of ways of making progress on this. First, it seems
>>> that having a separate "read-only" KeyStorage facility specified in the
>>> spec, particularly if we don't have evidence of implementation, should not
>>> hold up progress and block the resolution we made in our face-to-face as
>>> regards *not* specifying key storage outside a structured clone algorithm
>>
>> Let's just be clear about what was agreed at the face-to-face. There was a
>> discussion that was entirely about keys generated or imported by the
>> application (let's call them "temporary" keys for the purpose of this
>> discussion), which concluded that these were best stored in an existing
>> storage facility using the structured clone algorithm. The resolution was
>> even qualified as "for non-token-backed keys", which we could argue about,
>> but which I take to mean for temporary keys.
>>
>> Furthermore, at the face to face, albeit mostly by email and offline, but
>> also very briefly at the meeting, I raised the issue of pre-provisioned keys
>> and the fact that KeyStorage was the only way to access them at present. I
>> made it very clear we did not agree to removal of support for
>> pre-provisioned keys from the specification.
>>
>> So there is no way you can interpret the resolution at the face-to-face as
>> agreement to remove support for pre-provisioned keys.
>
>
> I am not saying "remove support for pre-provisioned keys". I am wondering if
> we can support use-cases with pre-provisioned keys without creating a whole
> new kind of separate storage for keys for reasons Ryan has explained
> earlier. Before introducing a new kind of storage mechanism, we have to make
> sure we really need it of course!
>
>>> - which currently would pass the key material to IndexedDB, but we would
>>> not specify that as IndexedDB could be replaced at some point.
>>>
>>> To get progress going and not spend all of our time on this issue, I
>>> would propose:
>>>
>>> PROPOSAL: The next heartbeat publication of the spec goes with the
>>> structured clone algorithm and a separate keystorage facility be dropped
>>> textually from the spec.
>>
>> It was important to us that the FPWD contained a means to access
>> pre-provisioned keys. We would have objected to going to FPWD if it did not.
>> And so we object now to any proposal to remove that support, without
>> replacing it with something else.
>>
>> Yes, there are issues to be addressed with pre-provisioned keys, but I
>> don't think you can say this aspect of the specification is any less mature
>> than anything else. And none of it is implemented yet.
>
>
> What would be useful also to see on record if who definitely would be OK
> with implementing a separate KeyStorage. In order to get through CR we need
> at least 2 implementers per feature, but we ideally want all implementations
> to pass the test-cases.

Again, I think we need to be clear here - independent of
pre-provisioned keys, there are a number of issues I've pointed out
with KeyStorage.

I'm not, despite the characterizations, hostile to all forms of
pre-provisioned or out-of-band provisioned keys. As an implementor,
we're very interested in this, and very much believe there are use
cases that are solved here, and can be done in ways that are not
hostile to user-privacy.

That said, we disagree with the urgency that the first version must
support this. Minimally, pre-provisioned keys should be treated
consistently.

I really, really, really do not want to see the result of this being a
W3C recommendation that refers to optional features that are only
implemented by single vendor or two, and then have desktop and mobile
browser vendors (and future device vendors) implement a different
recommendation that is more consistent and more developer friendly. I
strongly believe that the best solution to this problem is, like so
many other features with the web platform, to let the vendors gain
implementation experience before attempting to nail down the universal
specification. We do not want to end up in a situation of Web Storage
vs WebSQL vs IndexedDB, which, regardless of the vendor positions, has
been bad for the web developer communities.

>
>>
>>> We keep Keystorage open as a separate issue, we keep the issue open but
>>> table discussion of it till we get primary features finished. We'd also need
>>> implementers in the WG to step forward besides just Netflix.
>>>
>>> However, I might add key import/export *are* on the table. Can the
>>> Netflix use-case be addressed by having their browser import a
>>> pre-provisioned key with a guid attribute from an external storage location
>>> every time it starts would be probably be enough?
>>
>> Yes, this is another good possibility. We could overload import to
>> retrieve a key from an external storage location. If this was considered an
>> "Algorithm", then the optionality of this would be dealt with cleanly: we
>> know that different implementations will support different algorithms. Also
>> capability discovery, if we go there.
>>
>> For example, we could specify a new Algorithm that is used with
>> createKeyImporter, to import a key from an external origin-specific store,
>> with a key identifier as the single parameter (this would not be the guid,
>> it would be the 'name' of the key, to differentiate it from other keys in
>> the same store).
>>
>> I'd be happy to make a detailed proposal by the next call if others
>> (particularly Ryan) think this is a good approach.
>
>
> Editors - any feedback here?
>
> I would like to see if createKeyImporter could be used this way in a
> detailed proposal and I hope others from the WG would find this of interest.
> Thus, we could get "square the circle" and get both the implementation
> ease-of-use and privacy benefits of not creating a new kind of browser
> storage, and also solve this very important use-case.
>
> I imagine that such a detailed proposal could also be extended to deal with
> general ways of importing a key from an external key-store that could also
> help us solve the "multiple key container" issue, which could even address
> some of the smartcard issues as well as flesh out the issues of key
> import/export!

I think such an approach to managing pre-provisioned keys by importing
is, at first glance, both (technically) wrong and (semantically)
unintuitive. That said, if Netflix or others wish to implement
experiment with that approach, I think the spec as written currently
allows them to (just as the spec certainly allows them to experiment
with KeyStorage in practice).

However, I do not think the spec produced by this WG would be serving
the open web development community by implicitly or explicitly
recommending or requiring that approach.

As I've stated elsewhere, as we get closer to implementation, I do not
think we should be using the spec as the experiment ground for ideas
that may or may not work. Specifications live forever, for better or
worse, and bad decisions can have significant negative outcomes for
years, far beyond the short-term interop concerns.

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. If, as time and implementation
permits, we can address issues like key discovery, I am absolutely all
for it, as I have always been. However, speaking both as an
implementor and as one who has dealt extensively with cryptographic
libraries over the years, I think the suggestion that this is an
"easy" problem or that can be cleanly specified - let alone all of the
privacy and web platform implications (referred to elsewhere) - is
optimistically misguided.

This is why I'm repeatedly trying to focus on universally agreed upon
parts, and to make sure we have specified an API that's workable and
reasonable. And the best way to do that, with what we have now, is to
begin experimenting and implementing - on all relevant platforms - and
begin providing feedback to the work group. And realizing that, as a
result of such experience, the spec MUST be able to change.

Received on Thursday, 15 November 2012 22:56:51 UTC