Re: Key export and an opaque KeyFormat

Respectfully Mark, I disagree here.

I'd much, much, much rather ship something that is "not ideal, but
workable", rather than tack on short-term hacks/workarounds (which I
consider this, even if well-intentioned) that can never, ever be removed
from the web platform.

I'm not trying to suggest we let the perfect be the enemy of the good here,
but I am strongly a believer that we should not let expediency push us down
a poor design path - even if it's "just for hacking around with the API"

Plenty of IDB<->LocalStorage polyfills exist that can easily simulate your
desired behaviour in the interim, if it's truly a blocker for you. We
should NOT bake this into the spec without further consultation.


On Tue, Mar 26, 2013 at 3:07 PM, Mark Watson <watsonm@netflix.com> wrote:

> We have heard from more than one browser implementor that something like
> this would be useful in the short term.
>
> The concern for us is that if we wait until the "asynchronous local
> storage with structured clone" problem is solved to start working with
> WebCrypto we will be unnecessarily delaying the development and
> experimentation that needs to happen with WebCrypto for us to get
> everything else right.
>
> As a practical matter it would be good to include something like this to
> unblock development of the first WebCrypto apps.
>
> ...Mark
>
>
>
>
> On Tue, Mar 26, 2013 at 2:38 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>>
>>
>> On Tue, Mar 26, 2013 at 1:50 PM, Vijay Bharadwaj <
>> Vijay.Bharadwaj@microsoft.com> wrote:
>>
>>> So I tried this out (I hadn't used IndexedDB before) and while it is
>>> certainly powerful and elegant in its own way, I was surprised at how hard
>>> it was to replace localStorage with indexedDB for storing a couple of items
>>> in an existing script.
>>>
>>> Here is what I had to do (leaving out version and capability detection):
>>> 1. Try to open the database (to avoid more complexity, I ignore version
>>> numbers). If this succeeds, go to step 4.
>>> 2. If database blocked, handle that (in my case by displaying a fairly
>>> unhelpful message).
>>> 3. If database doesn't exist, start a version change transaction and use
>>> it to createObjectStore.
>>> 4. Initiate a transaction to read/write.
>>> 5. Read/write data asynchronously, and verify the transaction succeeded.
>>>
>>> This replaces localStorage code that is basically:
>>> 1. Try to read a value. This will fail if the value doesn't exist.
>>> 2. Write the value using a simple assignment.
>>>
>>> This replaces 2-5 lines of code with a page or more of code. I can see
>>> Mark's argument about simplicity - if someone just wants to store a key for
>>> crypto, we shouldn't also force them to become database experts.
>>>
>>> Would adding a key export format help us cater to a wider audience of
>>> developers? The increase in implementation complexity doesn't seem like
>>> much - it's basically a more direct interface to the same thing an
>>> implementation would do in its structured clone implementation.
>>>
>>
>> I'm certainly sympathetic to the concerns about IndexedDB (which was/is
>> largely intended to replace Web SQL - and address its particular use
>> cases), but I don't think it'd be wise for us to bake something into the
>> API purely on the grounds that localStorage lacks structured Clone. The
>> discussion of adding structured clone to local storage has happened in
>> WebApps. One of the big concerns was with it's synchronous nature, since
>> combining that with structured clone is a recipe for perf disaster (again,
>> due to JS blocking UI and friends).
>>
>> We can certainly raise it as a point for script-coord/the TAG, but I
>> would suggest that the idiomatic Web API is to look at using Structured
>> Clone - and not to try to provide multiple ways to skin that cat. If we
>> need simpler storage for structured clone (and certainly, count me among
>> those who favour it), then we should revisit localStorage - which, I
>> understand several people to be looking at, particularly when combined with
>> the DOMFutures discussion.
>>
>> Vijay, would you be comfortable if we created an issue specifically to
>> deal with structured clone and whether or not we should provide a
>> stringizing-form that is limited to the UA, and then reach out to the TAG?
>> Again, my gut is that the response will be "structured clone or bust", but
>> I don't want to prematurely cut off that discussion if this is an important
>> point on your end.
>>
>>
>>> -----Original Message-----
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Wednesday, March 20, 2013 6:50 PM
>>> To: Mark Watson
>>> Cc: Vijay Bharadwaj; public-webcrypto@w3.org
>>> Subject: Re: Key export and an opaque KeyFormat
>>>
>>> On Wed, Mar 20, 2013 at 7:16 AM, Mark Watson <watsonm@netflix.com>
>>> wrote:
>>> > This proposal would at least allow storage of keys in web storage -
>>> > which is universally supported, unlike IndexedDB. (Please correct me
>>> > if there is another storage mechanism with universal support).
>>>
>>> I don't think that's a fair or accurate measure, given the significant
>>> complexity it can introduce. Web Crypto has no support at this point.
>>>
>>> We should be working within the platform APIs and patterns, and not just
>>> throwing it all aside.
>>>
>>> Our charter calls for active liasing with Web Apps, the same way we work
>>> with JOSE. There are certainly people on this very list that would like to
>>> improve localStorage, in that it solves a 'simpler'
>>> problem than IndexedDB (which was/is an alternative to WebSQLDatabase).
>>>
>>> >
>>> > I don't think there is any privacy issue: if the implementation uses
>>> > an internal reference, then the internal store must be cleared when
>>> > the user clears other storage. If it encrypts the key data with a
>>> > local key, then so long as there is some kind of nonce in the
>>> > plaintext, guessing a valid opaque blob is as difficult as guessing
>>> > the internal key. Also, the plaintext could include a sequence number
>>> > which is incremented each time storage is cleared. Anyway, we would
>>> > simply state a requirement that keys exported this way should be able
>>> > to be imported again after storage has been cleared.
>>>
>>> My goal here is to keep the normative requirements of a conforming
>>> implementation as flexible as possible. This certainly does not do so, in
>>> my opinion - and it seems that the only justification for doing so is
>>> related to "Indexed DB is hard/not widely supported" and "localStorage
>>> doesn't support structured clone" (the latter largely due, AIUI, to the
>>> synchronous nature of the API more than anything)
>>>
>>> >
>>> > ...Mark
>>> >
>>> > Sent from my iPhone
>>> >
>>> > On Mar 20, 2013, at 3:55 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>>> >
>>> > Exactly. And there is no requirement that raw key material be stored
>>> > in the underlying storage - the only implementation requirement is
>>> > that, given a store and later load (eg: clone) it yields a Key object
>>> > that behaves the same.
>>> >
>>> > A conforming browser using CNG could thus implement this by storing
>>> > the opaque key. It could also implement this by storing a reference to
>>> > the KSP and key name. Or it could store the raw material. From the web
>>> > page side, all three possible implementations have the same behaviour,
>>> > and are thus conforming.
>>> >
>>> > On Mar 20, 2013 1:04 AM, "Vijay Bharadwaj"
>>> > <Vijay.Bharadwaj@microsoft.com>
>>> > wrote:
>>> >>
>>> >> Ah, I think I see now. I seem to have missed a lot of the structured
>>> >> clone conversation earlier.
>>> >>
>>> >>
>>> >>
>>> >> So with the structured cloning, something like
>>> >> transaction.objectStore("storename").put(key, "indexedDBkeyname")
>>> >> ought to work?
>>> >>
>>> >>
>>> >>
>>> >> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
>>> >> Sent: Wednesday, March 20, 2013 12:04 AM
>>> >> To: Ryan Sleevi
>>> >> Cc: public-webcrypto@w3.org
>>> >> Subject: RE: Key export and an opaque KeyFormat
>>> >>
>>> >>
>>> >>
>>> >> Perhaps I am not understanding the draft then. How is a script
>>> >> supposed to save a key (created by generateKey) for later use (i.e.
>>> >> across a browser restart for example)? Is the idea that generateKey
>>> >> also creates a key in some underlying persisted store?
>>> >>
>>> >>
>>> >>
>>> >> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> >> Sent: Tuesday, March 19, 2013 11:49 PM
>>> >> To: Vijay Bharadwaj
>>> >> Cc: public-webcrypto@w3.org
>>> >> Subject: Re: Key export and an opaque KeyFormat
>>> >>
>>> >>
>>> >>
>>> >> Vijay,
>>> >>
>>> >> Keys support structured clone. Just use the existing web storage
>>> >> mechanisms. Until the user clears storage, it works.
>>> >>
>>> >> This avoids any privacy concerns with accidental key resurrection
>>> >> through throwing opaque blobs at the user until one sticks (thus
>>> >> indicating they previously generated said blob, thus acting as a
>>> super cookie).
>>> >>
>>> >> No exporting is required for object cloning. This was a key point
>>> >> that has been repeatedly explained and a well understood concept from
>>> >> the Storage APIs and from Workers, which both use Clonability.
>>> >>
>>> >> On Mar 19, 2013 11:39 PM, "Vijay Bharadwaj"
>>> >> <Vijay.Bharadwaj@microsoft.com> wrote:
>>> >>
>>> >> It seems to me that the current API has little support for an origin
>>> >> which wants to generate a key and then use it for multiple sessions.
>>> >> The only way I can see in the API of doing this is to use exportKey
>>> >> and store the key in the clear. This is not an appealing prospect. It
>>> >> also means that if an origin wants to persist a key in this way for
>>> >> its own later use then it has no choice but to make it exportable.
>>> >>
>>> >>
>>> >>
>>> >> So I would like to propose adding a value "opaqueLocal" to enum
>>> KeyFormat.
>>> >> The behavior of this format would be as follows: the result of
>>> >> calling exportKey with this KeyFormat would be a durable key
>>> >> reference that would be bound to the particular machine (and possibly
>>> >> UA). The contents of this reference are opaque to the caller - it may
>>> >> be just a key name that refers to a local key store, or it could be
>>> >> the entire key object wrapped with a key held by the UA. Calling
>>> >> importKey on this result will work on the same machine and UA, but
>>> >> fail on all other machines. Also, the algorithm, extractable and
>>> >> keyUsages parameters will be ignored and the values from the original
>>> key object will be used.
>>> >>
>>> >>
>>> >>
>>> >> The concept is similar to BCRYPT_OPAQUE_KEY_BLOB in CNG:
>>> >> http://msdn.microsoft.com/library/windows/desktop/aa375434.aspx
>>> >>
>>> >>
>>> >>
>>> >> Thoughts?
>>>
>>
>>
>