W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25710] No Key Deletion

From: <bugzilla@jessica.w3.org>
Date: Mon, 19 May 2014 23:42:50 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25710-7213-N1cEUHy9ag@http.www.w3.org/Bugs/Public/>

--- Comment #4 from Matt Miller <mamille2@cisco.com> ---
(In reply to Ryan Sleevi from comment #3)
> (In reply to Matt Miller from comment #2)
> > As a user of the API, I do find it worthwhile to be able to explicitly
> > invalidate a key.  However, since the WG consensus seems to be to rely on
> > ECMAScript's object lifetime, I can live with this for now.  It would help
> > users of the API if that it were stated, even non-normatively.
> What's the use case for explicitly invalidating?
> How is explicit invalidation meant to operate
>   - when the user has multiple tabs open
>   - when the user has postMessage()'d the key to a worker
>   - when the user has postMessage()'d the key to another origin
> Note that answering any of these questions implies assumptions about a
> storage model, which as you noted, is something we've attempted assiduously
> to avoid. IndexedDB has largely addressed these (with a significant bit of
> complexity added to the underlying HTML spec to handle database locking
> semantics). Likewise, other APIs have outright refused to create
> multi-context aware objects (eg: ArrayBuffer being Transferrable, rather
> than Cloneable) for this reason.

I won't deny that there be dragons here.  As a user of the API, if I detect
that a key might be suspect (and there are a plethora of ways that can happen,
a lot of them application-specific), that I can make a call on
window.crypto.subtle to say "don't let this key be used again".  When any of
the other tabs/windows/frames tried to use the key, it would be rejected() with
some error (hypothetically "invalid key").

I completely understand there are synchronization issues within the user
agents, but I would find the above very worthwhile.

Absent that, it would be helpful to me (a user of the API) to read in the spec
that key deletion is explicitly out-of-scope and relies on the lifetimes
inherent to ECMAScript objects, and whatever extra-spec storage system I use
(e.g., IndexedDB).  I want to know what I'm getting into if/when I use this

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 19 May 2014 23:42:52 UTC

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