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

Re: KeyStorage and Pre-provisioned Keys: A proposal

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 15 Nov 2012 11:14:15 +0100
Message-ID: <50A4C077.4040808@w3.org>
To: Mark Watson <watsonm@netflix.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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.
>
>> 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!
>
> ů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 Thursday, 15 November 2012 10:14:25 UTC

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