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 24427 - Make all method failures asynchronous
Summary: Make all method failures asynchronous
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: Mark Watson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-28 18:02 UTC by Mark Watson
Modified: 2014-02-20 20:06 UTC (History)
3 users (show)

See Also:


Attachments

Description Mark Watson 2014-01-28 18:02:55 UTC
It's been suggested that all failures should be asynchronous. We currently have the following synchronous failure modes:
- unrecognized algorithm
- unrecognized key usage value
- unrecognized key format value
- required usage not present

These are all things which can be identified immediately without significant work, since they all involve comparing input data with data that is exposed as attributes on the Key object anyway.

We fail asynchronously for
- key type isn't correct for the algorithm
- key parameters don't match values specified in import or unwrap
- algorithm failure

Should we make all failures asynchronous ?
Comment 1 Eric Roman 2014-01-28 21:36:59 UTC
I am in favor of making everything be an asynchronous error! Justification below.

------------
- required usage not present
-------------

I feel strongly this should be an asynchronous error.

Prior to this being added to the spec as a synchronous failure, I interpreted this as being an asynchronous failure and implemented it as such for Chromium.

In my mind a mismatch on key usage is just one more instance of a "key error". Special casing this particular one as synchronous is inconsistent when there are numerous other asynchronous ones which might occur:

  - Key is not extractable
  - Wrong key type (i.e. gave a public key when expecting a private key)
  - Wrong key all together (i.e gave an HMAC key for an AES-CBC operation)

------------
- unrecognized key usage value
- unrecognized key format value
- unrecognized algorithm
------------

I also argue that these should all be asynchronous errors.

The current programming model is clumsy. Callers to WebCrypto must BOTH wrap every call in an exception handler AND provide a rejection handler. The is because no algorithm can be guaranteed as being present. Even worse, there is nothing in the spec that implies that doing a "feature probe" at the start prevents you from needing to catch exceptions later. Just because some algorithm was "supported" 10 minutes ago, doesn't necessarily guarantee that on all implementation it would be available later (sure this would be weird, but trying to make a point here :)

Having unhandled exceptions thrown is bad for the web, since it breaks pages unexpectedly, rather than failing gracefully when running on a different environment. If I were implementing something using today's WebCrypto I would create a wrapper around every invocation to avoid this problem.

Lastly, there is an issue of consistency. I can tell you from the Chromium implementation of WebCrypto that there are a vast number of errors that can happen for unsupported/unimplemented behavior, the majority of which are asynchronous.

To give some examples:

  - "JWK" is recognized as a valid key format so no exception is thrown. Cool. But does that really mean that it is "supported" - NO. Today if you try to import a JWK key specifying an RSA private key, it will fail, because that particular feature is not yet implemented. Similarly, certain flavors of key usage are not supported. So why should one flavor of "unsupported" be an asynchronous failure however the former is synchronous?

  - "AES-GCM" support for Chromium on Linux is weird. It is only available if the system's libnss is 3.15 or later (which on Debian it is not). The consequence is that when parsing the algorithm, "AES-GCM" is a registered name and the caller gets no synchronous UnsupportedError. However later when actually fullfilling the asynchronous operation, things may fail because dlsym() couldn't find the necessary symbols. Giving a more accurate signal and making this a synchronous error would be undesirable for our implementation.



So ultimately, I believe Javascript callers already must be prepared to handle asynchronous failures that are very similar in nature to the synchronous failures, so why make life harder for them by duplicating error handling.

The only argument I can make for these synchronous errors is that it allows for a very minimal feature detection. That said I think it is ill suited for feature detection, and such detection would best be handled by either a separate API, or by augmenting the asynchronous errors with a particular error type (instead of just "null").

Cheers.
Comment 2 Mark Watson 2014-02-06 19:48:08 UTC
If there are no further comments, I will implement this to make all errors asynchronous.