Re: Key export and an opaque KeyFormat

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