Bug 27598 - Clarification: Can NotSupportedError be thrown in places where the spec uses an OperationError?

[mwatson2]

Bug 27598:

There are some operational failures an implementation may have due to unsupported functionality.

For instance in Chrome:

• Importing or generating 192-bit AES keys is not supported
• Generating an RSA modulus < 256 bits or > 16384 bits is not supported
• Generating an RSA key with publicExponent not one of {3, 65537} is unsupported

My reading of the spec suggests that each of these errors must be an OperationError.

However I feel that NotSupportedError is more appropriate.

Is a confirming user agent allowed to throw NotSupportedErrors in places not explicitly mentioned by the spec?

[mwatson2]

I believe we decided to use OperationError rather uniformly since whether (and when) an implementation can detect a specific error / distinguish different errors may be depend on the cryptographic library in use.

[mwatson2]

Propose wontfix

[jimsch]

I believe that this needs to have text added someplace that states explicitly what is to be done if out of range values are specified. I am unsure what piece of the spec is being referenced when an import an an AES key is 192-bits is not supported by the browser. Not that if AES-GCM was not supported at all, it would return NotSupportedError as it would not be in the dictionary. But if you don'st support 192-bits then it returns either OperaitonError or DataErrror depending on the function being called? (Generate and Import w/ jwk respectively.)

[mwatson2]

As the spec is currently written, it is not an option to support AES-GCM but to not support one of the key sizes. This is why there is no step saying "If keys of size X are not supported do this."

If we would like to make support of specific key sizes optional, that would be a feature request. Likewise bounds on the RSA parameters.

[jimsch]

Given that statement, an error code of Not Supported is just as valid to be returned as any other error code would it not? If the spec is silent on what to do in this case there is no standard error message.

[mwatson2]

The answer to your original question:

Is a confirming user agent allowed to throw NotSupportedErrors in places not explicitly mentioned by the spec?

is no. But a non-conforming user agent can of course do whatever it likes :-)

Actually, I take back what I said about bounds on the RSA parameters. The RSA procedures include a generic step "if the operation fails throw an OperationError" without placing any restrictions on the kind of failures. The AES algorithms don't have such a get-out.

So, you can support or not whatever you like for RSA - but you can't use NotSupportedError - but for AES you have to support everything described.

Do people think we should specify minimum supported value ranges for the RSA parameters ?