Re: How to communicate error details for failed crypto operations

Per <https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md>, 

----------------------------------------
Promise rejections should always be instances of the ECMAScript Error type, just like synchronously-thrown exceptions should always be instances of Error as well.

In particular, for DOM or other web platform specs, this means you should never use DOMError, but instead use DOMException, which per WebIDL extends Error.
----------------------------------------

This document also suggests that no exceptions should ever be thrown from APIs that return promises, to avoid duplicate error-handling logic. This is somewhat fishy, as you'd have to convert WebIDL exceptions into rejections, and that would be very inconsistent with the rest of the web platform. Anyway, there is some discussion in <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740>.

- WBR, Alexey Proskuryakov

17 ΔΕΛ. 2013 Η., Χ 15:41, Eric Roman <ericroman@google.com> ΞΑΠΙΣΑΜ(Α):

> When a cryptographic operation fails, it rejects the Promise with null.
> 
> There is an editorial note to "Determine whether to reject the algorithm with a DOMError or a null result."
> 
> Has there been any further consensus on how to communicate errors?
> 
> ------------
> Background
> ------------
> 
> I am a developer for Chromium's (Promise-based) Web Crypto implementation.
> 
> My experience while writing tests is that the lack of error information can be a real difficulty when using the API.
> 
> There are a large number of errors that contribute to rejection of the Promise, and without details it is frustrating to pinpoint the problem. A simple typo on an AlgorithmIdentifier can have you bug hunting all over the place.
> 
> As a temporary measure during development I made Chromium throw exceptions synchronously with a descriptive error string for many types of errors: particularly AlgorithmIdentifier validation to check that required parameters are present and make sense, but also for key usage and extractability mismatches.
> 
> However I realize this is not in line with the spec, and I am now resolving the issue by switching to reject(null) throughout. I want to preserve the error information somewhere though, since I found it to be very valuable as a web developer.
> 
> At a minimum I can shove the error strings into the browser's devtools log.
> 
> Certainly this works, and doesn't require any changes to the spec. However the implication is that each implementation of Web Crypto may develop its own mechanism to surface error information for developers. So I want to bring this issue to the attention of the working group.
> 
> An alternative would be to pass error context to the reject() handler instead of null.
> 
> Not having followed the history of this decision, I appreciate that passing error information to reject() opens up a big can of worms with regard to which errors are enumerated, whether they are mandatory (which would be an implementation nuisance), and what impact it would have on web compatibility if different implementations surfaced different error details in a way that was inspectable by running applications.
> 
> ------------
> Sample errors
> ------------
> 
> To give a taste of the flavors of error being represented by reject(null), here some examples:
> 
> * Key usages does not allow for this operation
> * Key is not valid to use with this algorithm
> * Key is not extractable
> * Did not specify the "optional" algorithm when importing a key (and it couldn't inferred from the data).
> * The "optional" algorithm was inconsistent with that of the key data when importing key (ex: JWK).
> * A large slew of failures when interpreting the AlgorithmIdentifier's parameters for an operation (for instance specified an HMAC algorithm but the "hash" property wasn't a valid digest operation).
> * Unsupported key length
> * Invalid key length
> * Unsupported algorithm
> * Internal implementation failure
> * A large slew of JWK parsing errors when importing keys.
> * Wrong sized "iv" when calling AES-CBC
> * Invalid authentication tag length when calling AES-GCM
> * Plain text was too long when doing RsaEs
> * Ciphertext was too short
> * Public exponent too big when generating a keypair.
> .....
> 
> The majority of these are programmer errors (invalid inputs), and I feel the granularity of error detail should be up to the specific implementation.
> 
> There is also a class of implementation failures relating to unsupported algorithms/parameters, or internal failures.
> 
> Thanks for any feedback!

Received on Thursday, 19 December 2013 16:44:46 UTC