[Bug 25710] No Key Deletion

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

--- Comment #5 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Matt Miller from comment #4)
> (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").

Duly noted, although few (if any) existing cryptographic APIs permit this.
PKCS#11 doesn't (as operations are allowed to continue using the key - it's up
to the implementation), CryptoAPI/CNG doesn't consistently (the key is
refcounted, and even if storage is invalidated, if refs are holding on, they
can typically still access), and similarly CDSA.

> 
> 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 API.

Right. Totally happy to make sure this text is included in the "informative"
section of "Mapping these concepts to existing APIs/concepts developers are
familiar with, for those that are new to web programming"

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

Received on Tuesday, 20 May 2014 00:02:47 UTC