W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2013

Re: Failure mode for Key-based operations

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 12 Jun 2013 11:49:45 -0700
Message-ID: <CACvaWva9XUmbtfi+xnE95OHwuvpt=3uWdLgAqz2=NhX3t2of9g@mail.gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Tue, Jun 11, 2013 at 1:21 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> Ryan,
> On Jun 4, 2013, at 6:52 PM, Ryan Sleevi wrote:
>> As mentioned on our call yesterday, I'm curious for input on the
>> expected failure mode for key-based operations
>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/0e4d8673531e/spec/Overview.html
>> For example, generateKey describes the error handling mode as invoking
>> the resolver's reject algorithm, with 'null' as the value.
> Can this discussion also apply to encrypt(), decrypt(), sign(), verify(), and digest()?

Well, there are some potentially user-actionable errors in those cases
- for example, if inputs need to be of a certain size (eg: block
aligned), that may signal an action the author can take. There's also
the possibility that the underlying key data for the Key object was
removed (either before or during the operation), which may lead to an
actionable difference.

Which is to say, I think we can make an argument that the
CryptoOperation needs DOMErrors, but I'm having a harder time fitting
that in with KeyOperation.

>> A thought occurred to me as to whether or not we should be generating
>> a DOMError when rejecting - eg:
>> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domerror
>> This would be akin to the FileReader interface (eg:
>> http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException ), which
>> describes a mapping between particular DOMErrors and states of the
>> FileReader.
>> However, to be clear: I'm NOT trying to advocate the "Let's introduce
>> 100 unique error codes for <insert vendor solution> here".
>> Unless there are compelling answers to the following questions, I
>> consider the reject-with-null to be the most appropriate response.
>> 1) What are the types of errors that can occur when performing Key operations
> generateKey -- no meaningful error outside of WebIDL or the spec. (which can handle parameter inconsistencies by throwing, like algorithm normalization failure).
> deriveKey -- there's one fail state which involves "terminating this algorithm with an error" (step 6) which isn't defined (although "terminate the algorithm" is defined).  Do you mean to throw an InvalidStateError exception here?    Can Step 6 be part of the error steps in Step 5, in which case you'd return an InvalidStateError DOMError?


So, Step 5 is meant to describe what "terminate with an error" does.
This is why, for example, wrapKey repeats this phase (Step 7, 9, 11 of

The question is, if a DOMError is to be run through the rejection
algorithm, what do we expect the DOMError to be? Or is your thinking
that just any error case should be a DOMError?

I'm trying to find if there's any discernible differences that can
lead to an author changing code to work.

> importKey -- probably nothing more than JWK or format errors, which the spec. already solves for.  If "KeyFormat" is "jwk" keyData still has to be an ArrayBufferView?

Thanks for bringing this up again. This was something that went
unresolved in discussions with Mark, and may be worth discussing
again. The question was whether to allow (DOMString ||
SomeNewDictionaryType) to be specified as KeyData when using a JWK. If
it is a DOMString, what does it mean - something that will parse with

> exportKey -- same as in deriveKey, there's a "terminate this algorithm with an error" in step 7.  Exception?  Can it be rolled into the error steps with a DOMError?
>> 2) If an error is generated, can the script author take any form of
>> action based upon understanding the nature of the error? eg: Can they
>> alter input parameters such that it succeeds, or is it a "Failure is
>> failure" mode?
> Only in changing Key.extractable OR .keyUsage; I think everything else is format diligence, so a null result will probably mean reworking code to look at those things.
>> As much as I'm all in favour of exposing additional data, if the error
>> status cannot result in actionable distinctions, I think it merely
>> complicates the API for now end-user improvement.
> +1.  I'm not pushing strongly for DOMError, only pointing out what caused me a reader's blip.
> -- A*
Received on Wednesday, 12 June 2013 18:50:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC