KeyStorage and Pre-provisioned Keys: A proposal

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

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?

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 10:33:34 UTC