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 27564 - Must conforming implementations match the order of errors?
Summary: Must conforming implementations match the order of errors?
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-11 03:35 UTC by Eric Roman
Modified: 2016-05-23 23:55 UTC (History)
3 users (show)

See Also:


Attachments

Description Eric Roman 2014-12-11 03:35:36 UTC
My interpretation of section "3. Conformance" is that yes, the order of errors must match that enumerated by the spec's pseudo-code.

I would like to relax this requirement since some of the error orders given by the spec restrict implementations.

For instance:

   * Empty usages is tested _after_ having generated/imported a key. However it would make more sense for an implementation to test for this error before creating the key (also faster failure for caller)

   * Usage testing when unwrapping a key is done after decryption (as part of importKey). Whereas implementations could rejected invalid usages (in many cases) sooner before doing the decryption.
Comment 1 Mark Watson 2015-01-05 17:41:34 UTC
Won't it make the test suite very complex if different implementations can return different errors for the same input (because they perform checks in a different order) ?

Or am I being optimistic to think that the test suite would get as far as testing combinations of multiple input errors ;-)
Comment 2 Eric Roman 2015-01-07 02:19:37 UTC
Perhaps then I should file individual bugs for the error orders I am not satisfied with.
Comment 3 jimsch 2016-03-04 00:18:16 UTC
Based on my reading of the current section 3 I would disagree that the order of errors is strict.  The text states that the algorithms are laid out to be understandable not to be high performance (although I have never run across the word performant and would probably say it could be changed).  

For single errors, the correct error needs to be returned.  For multiple errors, I would say that any of the errors can be checked first and returned.
Comment 4 Ryan Sleevi 2016-03-04 00:35:04 UTC
(In reply to jimsch from comment #3)
> Based on my reading of the current section 3 I would disagree that the order
> of errors is strict.  The text states that the algorithms are laid out to be
> understandable not to be high performance (although I have never run across
> the word performant and would probably say it could be changed).  

But also that the observable effects remain the same.

The observable effects include errors.

So yes, the order of errors is strict.
Comment 5 Mark Watson 2016-05-23 23:55:37 UTC
Moved to https://github.com/w3c/webcrypto/issues/50