[Bug 25711] Not clear if keys persist across sessions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25711

--- Comment #3 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Kelsey Cairns from comment #2)
> So I guess the larger problem is not so much confusion at the level of how
> behaves. In my mind it's branching into two new directions which should
> possibly be different bugs. 
> 
> I still need to think about the how-keys-behave direction. But the
> lack-of-clarity direction is more a matter of discrepancy between the actual
> API spec and what the use cases and structure would lead one to think. 
> 
> 
> If you want an example of what I'm thinking, consider the word "import" with
> respect to keys. There are many possible interpretations here, but it seems
> to me that a very natural one suggests transferring a key from the outside
> world into some local storage for many keys. The semantics WebCrypto has
> chosen is different in that the container into which a key is imported is
> more of a wrapper -- something that holds a single key in a way to make it
> useable with the rest of the API. Both interpretations make sense; The
> chosen language (import/export) doesn't imply that we're *not* talking about
> a general keystore.
> 
> Okay. So the phrase "agnostic to underlying key storage mechanism" is near
> the top of the spec somewhere. Really, anyone who reads that shouldn't be
> confused by the import/export language.
> 
> Now consider all the use cases. The first use case mentioned dives into a
> description that very implies that users can authenticate in later sessions.
> The phrase "proving that the user has access to some secret keying material"
> implies persistent keys. The use cases continue, suggesting (and even
> relying on) persist storage but glossing over the details.
> 
> So all in all, here's my conclusion: yes, the API specifically states how
> keys work. But the surrounding language and discussion aren't consistent
> with what is specified by the API and what is out of scope. Given that it's
> an English language document and its readers are humans, I think this might
> be one of the things causing so much general confusion.

So, trying to unpack this a bit...

As a result of the TAG review, I'm adding a section that introduces and
explains some of the terminology used in the document - cryptographic
providers, key handles, etc. It sounds like an addition to this (non-normative,
informative) section, a basic description of how key storage works with the API
and how it conceptually maps to these APIs might mitigate the concern.

That is, explicitly (re-stating) that storage of keys is not provided by this
API, but it can be implemented using a variety of ways. One way is using
IndexedDB, which is a per-origin storage mechanism that accepts objects that
support Structured Clone. Implementations can store, query, and delete Key
objects from IndexedDB, and these Key objects will only be accessible to their
origin by virtue of IndexedDB's security restrictions.

They can also share keys with other origins, but it must be done explicitly (at
the script's request), using techniques like postMessage, which allow you to
send any Structured Clone-able object to another origin, provided you have a
handle to that origin (eg: a cross-origin iframe)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 15 May 2014 17:08:59 UTC