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 27603 - verify() can fail either by returning flase or rejecting with an error, inconsistent which is used
Summary: verify() can fail either by returning flase or rejecting with an error, incon...
Status: RESOLVED MOVED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-13 02:25 UTC by Eric Roman
Modified: 2016-05-24 00:08 UTC (History)
3 users (show)

See Also:


Attachments

Description Eric Roman 2014-12-13 02:25:25 UTC
There are two ways for crypto.subtle.verify() to fail verification:

  (1) Resolve the promise with false
  (2) Reject the promise with an error

There are inconsistencies between algorithms on which approach is chosen, and there are also implementation complexities that arise from the distinctions.

For instance:
 
 * In the case of ECDSA the spec treats all verification failures the same way, but returning "false".

 * In the case of RSASSA-PKCS1-v1_5 the spec says to reject with an OperationError "If performing the operation results in an error".


I haven't run a full set of tests yet, however I am uncertain that the popular crypto libraries consistently distinguish errors for RSASSA-... and RSA-PSS in the manner required.
Comment 1 Mark Watson 2015-01-05 18:08:10 UTC
The original intention was that 'false' is used for cases where all the parameters are valid, the cryptographic operations succeed, but the final signature value just doesn't match the one provided. Other cases would be an error.

We should resolve this in favor of what libraries provide. If there is an example library which does not expose the distinction then I guess we should move them all to errors.

If the distinction is generally available, then we need to make the specification consistent with the original intention.
Comment 2 jimsch 2016-03-04 01:56:06 UTC
I have been going through the list of things that I would consider to be both an operational error and would not be considered to be a security error.  For example, one could conceivably make the fact that after the decryption is done the structure of the internal data is incorrect is an operation error, but this is a known security attack and should return as a signature validate failure (i.e boolean=false).

NotSupported is correct for an error of not supporting an operation.  The only thing that I can think of that would lead to an OperationError would be a transient error where a hardware failure occurred or similar condition.

I would recommend that we just remove the step dealing with OperationError entirely.
Comment 3 Mark Watson 2016-05-24 00:08:44 UTC
Moved to https://github.com/w3c/webcrypto/issues/66