W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2012

Re: ISSUE-1: Mandatory algorithms (was Re: ISSUE-3: Algorithm discovery)

From: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Date: Tue, 10 Jul 2012 13:51:34 -0600
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>, Michael Jones <Michael.Jones@microsoft.com>
Message-ID: <CC21D095.496E%s.durbha@cablelabs.com>
I was not arguing against defining the exceptions. It is definitely a required feature, we need to define them. I agree that algorithm discovery is needed.

I was just commenting on the reference to ISSUE-1 - mandatory list (sorry for the confusion).

So, with respect to ISSUE-1…

>>When there (and there eventually will) exist two different sets of MUST-IMPLEMENT, how will the web application behave then? When SHA-1 is broken, or SHA-3 is the new MUST-IMPLEMENT, how will that be addressed?

I am not sure how there can be two (or more) MUST-IMPLEMENT sets. The whole point of a standard is avoiding confusion.
On the second sentence, "when SHA-1 is broken…", I would like to see it 'deprecated', rather than 'removed' from MUST-IMPLEMENT, for a period of time. In my work, I see that there are hard reasons why people need 'legacy' support. When people do decide they are ready to migrate to SHA-N, catching the exception makes sense – because, they would have put in place a migration strategy for moving from SHA-1 to SHA-N, and that strategy is what goes into the catch block. I do not see a reason for any catch block logic from day 1. If we do not provide mandatory algorithms, what do we expect people to put in the catch block?



On 7/10/12 11:43 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:



On Tue, Jul 10, 2012 at 10:22 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
On 7/9/12 7:26 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

>>Note that none of the above semantics would necessarily be altered by a MUST-IMPLEMENT registry (ISSUE-1), since there would still
>>need to be some form of error handling for invalid constants/strings and for unsupported key+algorithm+operation tuples.

The difference is whether the developer needs to 'explicitly' catch UnsupportedAlgorithmException and 'do something about it', or 'just not bother', as the algorithm they picked is guaranteed to be available.

Errors caused by invalid constants/strings must be caught at development time.



I do not believe this is a reasonable approach, nor does it seem to be encouraged by the recommendations for W3C standard web APIs. [1] [2] [3].

My comment was reflecting a the need to have the error handling state machine fully defined in the spec. Failing to specify what happens when an invalid constant/string is provided means the API is incomplete, and developers have no way of knowing what will happen. Will the U-A just crash? Will the API ever call the onerror callback? If not, what happens if the user keeps calling processData() and supplying more data? Will it cause a syntax error that causes all JavaScript to fail executing on the page?

When there (and there eventually will) exist two different sets of MUST-IMPLEMENT, how will the web application behave then? When SHA-1 is broken, or SHA-3 is the new MUST-IMPLEMENT, how will that be addressed?

If we update the specification, and say "SHA-1 is no longer MUST-IMPLEMENT because it was broken", what does that mean for web applications that were using SHA-1? What will their execution environments be like? Will it break all script on that page?

For interop testing and for reference implementations, I do not believe we will be able to escape the need to specify error handling. Which is why I believe that these concerns remain wholly independent of the discussion of MUST-IMPLEMENT question. Because we MUST have error handling, we implicitly have discovery. The only question is whether we want to use error handling as the /only/ form of discovery.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0058.html
[2] http://scriptlib-cg.github.com/api-design-cookbook/#don-t-use-numerical-constants
[3] http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis#privacy-enhancing-api-patterns
Received on Tuesday, 10 July 2012 19:52:06 UTC

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