Re: KeyStorage and Pre-provisioned Keys: A proposal

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.

> - 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.

> 
> 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.

…Mark

> 
> Then, what would be needed is work on the spec figuring out how key import/export work in detail. Which is definitely needed!
> 
>   cheers,
>       harry
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

Received on Tuesday, 13 November 2012 17:10:49 UTC