This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25710 - No Key Deletion
Summary: No Key Deletion
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-14 12:46 UTC by Kelsey Cairns
Modified: 2014-06-16 23:20 UTC (History)
2 users (show)

See Also:


Attachments

Description Kelsey Cairns 2014-05-14 12:46:16 UTC
There seems to be no way to delete a key object. An application might
create many keys during a session (e.g. symmetric keys for encrypted
chat or encrypted email) that it no longer needs. One should be able
to delete them.

Perhaps the intention was to allow the user to delete keys, like
cookies? If so, this should be clarified.
Comment 1 Ryan Sleevi 2014-05-14 16:10:08 UTC
(In reply to Kelsey Cairns from comment #0)
> There seems to be no way to delete a key object. An application might
> create many keys during a session (e.g. symmetric keys for encrypted
> chat or encrypted email) that it no longer needs. One should be able
> to delete them.
> 
> Perhaps the intention was to allow the user to delete keys, like
> cookies? If so, this should be clarified.

I'm fairly certain this bug is invalid, but I would like to see if there isn't any changes needed.

Javascript does not have deletion semantics. Instead, it has scopes - and when a Key goes out of active scopes, it's no longer valid/accessible. While it's still bound to a scope - including the global scope - it is.

If the scopes change - eg: by navigating to a different page - than all objects are invalidated.

This is a standard part of the language, which is why the spec does not say anything. It would be akin to filing a bug against a C++ spec saying "Spec does not say when destructor is run" - even though the language itself is quite clear when destructors are run.
Comment 2 Matt Miller 2014-05-19 23:08:08 UTC
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.
Comment 3 Ryan Sleevi 2014-05-19 23:29:11 UTC
(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.
Comment 4 Matt Miller 2014-05-19 23:42:50 UTC
(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 API.
Comment 5 Ryan Sleevi 2014-05-20 00:02:46 UTC
(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"