Re: Rethinking KeyStorage

Ryan, all,

I'm sorry I missed the discussion of this. Can you explain how the application would find the Key object for a pre-provisioned key in the proposed new model ? It's clear how this is done with KeyStorage, so if you're going to remove KeyStorage we need a solution in the new model too.

…Mark

On Oct 29, 2012, at 3:12 PM, Ryan Sleevi wrote:

> Within the current draft API, there is an IDL specification for
> KeyStorage [KEYSTORAGE] that is largely modelled after the Storage API
> [LOCALSTORAGE].
> 
> There are several concerns with this approach:
> 1) The normal concerns regarding synchronous vs asynchronous
> interfaces ( ISSUE-31 )
> 2) The "weirdness" of acquiring a Key via a numeric ID
> (window.crypto.keys[3] / window.crypto.keys.getKey(3) )
> 3) That it introduces yet-another-tracking mechanism by providing a
> persistent storage space for web applications to use and possibly
> abuse. ( [PRIVACY] )
> 4) Confusion regarding there being (string) keys to lookup values that
> are Key objects (name/value pairs is an alternative name for key/value
> pairs, but it's still a little confusing)
> 5) Ambiguities regarding "temporary" ('session') keys and "permanent"
> ('persistent') keys and how one acquires references throughout.
> 6) The general sentiment that "Storage API is a bad API" (from
> Mozilla, Chromium, Apple, and Opera) - see
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
> 
> I'd like to propose an alternative means of dealing with KeyStorage,
> which involves entirely removing the KeyStorage object.
> 
> Rather than introducing a new storage type, I'd propose we make use of
> existing web storage mechanisms to store Key objects. This *does not*
> require storing the raw keying material in the same implementation
> used to back the various storage APIs - just that the object has
> defined semantics with regards to the structured clone algorithm. This
> is similar to how both Blob and File objects can be stored in existing
> storage APIs, without requiring that the raw data be persisted through
> those implementations.
> 
> For details on the structured clone algorithm -
> http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data
> . This would allow them to be stored in IndexedDB [INDEXEDDB], along
> with any number of attributes or other associated data.
> 
> Based on the feedback I've received internally, I think there is
> significant concern that KeyStorage is not a generally workable
> solution, so I feel we'll need to rethink key storage mechanisms if
> this proposal is unacceptable.
> 
> 
> [KEYSTORAGE] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyStorage-interface
> [LOCALSTORAGE] http://www.w3.org/TR/webstorage/
> [INDEXEDDB] http://www.w3.org/TR/IndexedDB/
> [PRIVACY] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#privacy
> 
>

Received on Thursday, 1 November 2012 15:21:42 UTC