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

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

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Thu, 12 Jul 2012 00:01:23 +0000
To: Eric Rescorla <ekr@rtfm.com>, 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>, Mike Jones <Michael.Jones@microsoft.com>
Message-ID: <382AD43736BB12439240773F68E907739A2432@DF-M14-24.exchange.corp.microsoft.com>
This is a great point, especially since if the browser delegates crypto to the platform, the decision on availability of an algorithm is up to the system administrator and not the browser.

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Tuesday, July 10, 2012 3:06 PM
To: Ryan Sleevi
Cc: Seetharama Rao Durbha; public-webcrypto@w3.org; David Dahl; Mike Jones
Subject: Re: ISSUE-1: Mandatory algorithms (was Re: ISSUE-3: Algorithm discovery)

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.

Received on Thursday, 12 July 2012 00:03:12 UTC

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