ISSUE-8: Clean key neutering (was Re: New Editor's Draft)

On Tue, Aug 28, 2012 at 8:08 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> On Aug 27, 2012, at 8:50 PM, Ryan Sleevi wrote:
>> On Wed, Aug 22, 2012 at 2:33 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>>> On Aug 17, 2012, at 5:48 PM, Ryan Sleevi wrote:
>>>
>>>> On Tue, Aug 14, 2012 at 9:32 AM, Vijay Bharadwaj
>>>> <Vijay.Bharadwaj@microsoft.com> wrote:
>>>>> I agree with Arun that we should support key neutering of some sort.
>>>>>
>>>>> Keys are in fact significantly expensive objects to set up.
>
>
> <snip />
>
>
>>>
>>> [GCvsExpensiveResources] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16952#c2
>>> [NOTransferable] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18611
>>>
>>
>> Perhaps incorrectly, but I've been conceiving as Key objects as
>> similar to object URIs. There are not the data in and of themselves,
>> merely a promise to provide that data when needed (eg: for a Crypto
>> Operation).
>
>
> That seems a safe enough assumption, but just to clarify:
>
> 1. An object uri *today* is merely a string; we use the term "dereference" (for lack of a more robust term in all of HTML5) to describe how a Blob is "dereferenced" with the object uri.
>
> 2. A Blob is a "snapshot" at a specific timestamp of a File object.  It's not the file itself.  I owe a work item to the WG to clarify this to WebApps [BlobSnapshot].
>
> Could we be better served if the Key object in our API is conceptually closer to 2. than to 1.?  As you point out below, there's a variety of APIs, secure element semantics, etc., but what if Key is to [underlying key] just as Blob is to file reference?

I suspect 2 to be problematic - I think in part due to how
(underlying) keys behave and change. Unlike Files, one does not
generally mutate an (underlying) key - changing a key's data is
typically something that yields a new (underlying) key.

That said, I hadn't fully considered the ephemeral key case, in which
an (API) Key may in fact be responsible for keeping alive an
(underlying) key, and that (underlying) key may be a precious/limited
resource.

According to your [GCvsExpensiveResources], this seems to very much
argue in favour of explicit neutering (ISSUE-8)

>
>
>> A Key object does not necessarily represent a handle to an
>> underlying data store - I'm not sure that any object COULD reasonably
>> guarantee such a behaviour, given the wide variance of APIs, smart
>> cards, and secure element semantics regarding how many parallel keys
>> they can have open at a time.
>>
>> The closest the semantics of close seem to be akin to revokeObjectURL.
>> However, I'm nervous comparing it to even that, since naturally one
>> thinks of autoRevoke = true as part of the objectURLOptions, whereas
>> I'm not sure if the same makes sense for Key objects. In particular,
>> consider accessing common keys (whether window.crypto.keys or via some
>> query mechanism). Unless there was a way to say "Don't auto-revoke
>> THESE keys", you'd only be able to use them for a single operation,
>> before you need to re-query/re-get the Key handle. Surely, that seems
>> inefficient/wrong.
>
> Well… you *could* have the conceptual equivalent of autoRevoke = false :)
>
> Either way, whether via autoRevoke semantics, or .close() semantics, the case for being able to make key access a no op (via the existing "in memory" objects) at some point hasn't been fully fleshed out.  Are we doing this for memory management, security, or both?  You make the case that whatever our Key object is, it's probably not terribly expensive.  Is it desirable to let it linger?

Resource management, moreso than memory management. Keys rarely occupy
much memory, but they may themselves represent scare resources (eg: if
implementing atop secure elements/smart cards).

Thus it does seem like we need some form of neutering, with the
following semantics:
- If a Key is .close()d, it is neutered
- If a Key is a permanent key, and it is removed from
window.crypto.keys, all existing references are neutered (closer to
the #2 semantics from above, basically to handle if the underlying key
store is mutated explicitly by the app)

>> For persistent keys, the equivalent to revokeObjectURL would be the
>> KeyStorage.removeKey method. It seems like that could/should be
>> normatively spec'd to invalidate any references to that key (including
>> any in-progress operations), trigger the CryptoOperations onerror
>> handling, etc.
>>
>
> Possible -- what's the default? :)

It doesn't auto-remove keys.

KeyStorage.removeKey is about removing the permanent Key (and
underlying key) from the underlying storage. Any (API) Keys that refer
to that key are invalidated, and the (underlying) key is removed,
hence where it triggers the error. This would be closest to File API's
snapshot state change detection.

>
>
>> For ephemeral keys, dropping the object should be sufficient -
>> especially since the ephemeral keys don't live in window.crypto.keys
>> (which only contains 'persistent' keys)
>>
>
> "Dropping the object" = GC?

Yes, but I've now convinced myself this doesn't work in practice.

>
>
>> As far as "spec smells" go, how does the above proposal smell to you, Arun?
>>
>
>
> It has a pleasing bouquet of "possibly on the right path" to it :)
>
> -- A*
> [BlobSnapshot] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746

Received on Tuesday, 28 August 2012 19:05:26 UTC