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

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 10 Jul 2012 15:06:17 -0700
Message-ID: <CABcZeBPw_k2q7gwkxBvReqTgHxbkP=B3Pvkn7dWOxupPtwNbcQ@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Seetharama Rao Durbha <S.Durbha@cablelabs.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>, Michael Jones <Michael.Jones@microsoft.com>
On Tue, Jul 10, 2012 at 10:43 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Tue, Jul 10, 2012 at 10:22 AM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>>
>> On 7/9/12 7:26 PM, "Ryan Sleevi" <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?

FWIW, I think web applications always have to be prepared to behave in
some sane way if algorithms are unavailable, including mandatory algorithms.
It's not OK to (for instance) delete all my email just because the browser
vendor decided not to implement SHA-1.

-Ekr
Received on Tuesday, 10 July 2012 22:07:25 UTC

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