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

Re: ISSUE-31 Re: KeyStorage and Pre-provisioned Keys: A proposal

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 19 Nov 2012 10:22:36 -0800
Message-ID: <CACvaWvaTc2Ca1vJP-nW6GsokUg2+JhX0raY1VwRekbVOVkLRfQ@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
>> Is it possible that Netflix can come up with a solution to pre-provisioned same-origin keys
>
> We're working on a couple of options and will send these out today or tomorrow.
>
>> that involves "getKey/getKeyByID" that handles ISSUE 31, i.e. "a way to discover keys based on particular attributes, either intrinsic attributes or custom, user-defined attributes". Note that this ISSUE 31 would still stand when KeyStorage is removed and all keys are in localStorage/IndexedDB.
>
> Our proposals would replace KeyStorage for pre-provisioned keys, so if one of them were agreed, KeyStorage could then be removed. I don't think there's any proposal to store "all keys" in IndexedDB - this certainly wasn't what was agreed at the f2f - and I don't think local storage can be used to store keys, because the values are just DOMStrings, right ?

As was discussed during the F2F, all Key objects can be stored in
IndexedDB (or any other storage mechanism supporting the structured
clone).

As was described during the F2F, having a Key object presumes that the
caller is permitted to know about the Key's existence. That is, there
is no need for a page to "re-discover" a key on every page load, which
may, depending on user agent, involve additional prompts and/or
permissions. Storing it in an appropriate web storage system allows
the caller to retrieve and/or share access to the key, until such a
time as storage is revoked.

But yes, the proposal is exactly that - the only *storage* of Key
objects be accomplished via existing web storage mechanisms. Any
discovery of any pre-existing keys (inc. pre-provisioned) be
accomplished via key discovery mechanisms.

>
> I'm looking at options where different methods for querying and discovering keys can be added as "algorithms". This avoids introducing a new pattern for optionality and means we can address simple cases with a simple algorithm without having to address the entire key discovery problem captured in ISSUE-31.
>
> ůMark

As mentioned previously, this does not sound like a suitable approach
to addressing the technical concerns raised. While I wait to see a
proposal, I would simply request that an approach that is internally
and externally consistent with the needs raised in ISSUE-31 be
proposed.
Received on Monday, 19 November 2012 18:23:03 UTC

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