Re: WebCrypto Spec Error Types feedback from MS

On Tue, Mar 4, 2014 at 6:23 PM, Israel Hilerio <israelh@microsoft.com>wrote:

>  As promised, below is MS feedback on the types of error we believe are
> useful to expose to web developers.  We correlated this information with
> what was done on IndexedDB.  In addition, we when through Section 14.3 and
> mapped our proposed error types to steps on each section:
>
>
>
> Error Type
>
> Description
>
> Spec Mapping
>
> NOT_SUPPORTED_ERR
>
> The Algorithm is not supported
>
> 14.3.1 through 8, 11:
>
> * Step 6
>
> 14.3.7:
>
> * Step 7
>
> 14.3.9:
>
> * Step 5
>
> 14.3.12:
>
> * Step 6
>
> * Step 7
>
> SYNTAX_ERR
>
> Missing parameter errors.  For example, you fail to provide an IV for CBC
> Mode or not providing a key length when one is needed.
>
> 14.3.1 through 12:
>
> * Steps 1 and 5
>
>
>
> INVALID_STATE_ERR
>
> An invalid operation was performed on an object instance. For example, you
> have exceeded the number of operations allowed with a key.
>
> 14.3.1 through 4, 8, 11:
>
> * Step 8
>
> 14.3.7:
>
> * Step 12
>
> 14.3.10:
>
> * Step 6
>
>
>
> DATA_ERR
>
> Data provided to an operation does not meet requirements. For example,
> your plain text is not padded to the correct size.
>
> 14.3.1 through 5:
>
> * Step 8
>
> 14.3.6:
>
> * Step 7
>
> 14.3.7:
>
> * Step 9
>
> 14.3.9:
>
> * Step 6
>
> * Step 7
>
> * Step 8
>
> 14.3.10:
>
> * Step 5
>
> 14.3.11:
>
> * Step 7
>
> 14.3.12:
>
> * Step 9
>
> * Step 10
>
> * Step 11
>
> * Step 13
>
> UNKNOWN_ERR
>
> This is a system level transient failure that don’t necessarily indicate a
> failure in the program logic. For example, out of memory conditions.
>
> This could happen in any step
>
> INVALID_ACCESS_ERR
>
> An invalid operation was perform in an object type.  For example, you try
> to encrypt with a signing key.
>
> 14.3.1 through 4, 8, 9:
>
> * Step 7
>
> 14.3.7:
>
> * Step 8
>
> 14.3.11:
>
> * Step 8
>
> * Step 12
>
> 14.3.12:
>
> * Step 8
>
>
>
> Remember you’ll need to update step 4 on each 14.3.x to return DOMError
> and remove editorial note.
>
>
>
> We were also wondering if the following steps should be in the spec (they
> seemed redundant):
>
> ·        Section 14.3.11 Step 13
>
> ·        Section 14.3.12 Step 12
>
> ·        Section 14.3.12 Step 14
>
>
>
> Let us know if you have any questions.
>
> Thanks,
>
>
>
> Israel
>

Regarding UNKNOWN_ERR and DATA_ERR, doesn't that require taking a normative
dependency on IndexedDB, which defines UnknownError and DataError? I do
agree it's useful, I'm just not sure how to handle this. Do we equally
define an UnknownError? Is such a thing even possible?

Regarding the redundant sections, I agree, they seem redundant, because it
seems to be covered by Section 14.3.11 Step 4 ("If an error occurs, run
these substeps and then terminate the algorithm")

That said, we probably need to smith the language, since really it seems
like Step 4 will never be hit (except perhaps in Step 5?) For example,
Steps 6, 7, 8, 9, 11, and 12 all separately say "Terminate this algorithm
with an error" - which presumably means _don't_ run Step 4.

Spec bug!