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

On 07/10/2012 10:04 PM, Ryan Sleevi wrote:
> On Tue, Jul 10, 2012 at 12:51 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>> 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?
> Every time we modify the standard, there will be N versions of the
> standard, because there will be user agents that implement version 1,
> version 2, version 3, etc. Web applications that wish to work with
> these user agents must be prepared for each user agent having a
> different view of what "MUST-IMPLEMENT" means, which is why I don't
> think there's any particular added value in MUST-IMPLEMENT.
>
> Just like web applications today cannot assume that all user agents
> accessing their site support CSS4 selectors, web applications will
> have to be prepared for user agents that may (no longer / not yet)
> support the desired algorithm.
>
> And while I agree that it would be nice for a period of "deprecation",
> I would rather not have the matter of determining when to go from
> "deprecated" to "removed" be decided by committee. Different browser
> vendors have different views on security, and they have different
> value-tradeoffs: Some U-As may be focused on a particular market
> segment where no old feature can be removed, while other U-As may be
> focused on market segments where security is the most important
> aspect.
>
> Having the standard dictate MUST-IMPLEMENT means that U-As will lose
> the flexibility to make independent security choices while still being
> a compliant implementation. For example, a U-A may decide to go from
> implemented -> disabled by default, and require a user to explicitly
> enable it before it's available. Under a MUST-IMPLEMENT scenario, this
> would be non-compliant behaviour.
>
> Aside from theory, I think as an implementor, if we had security
> concerns with an algorithm that we believed put our users at risk,
> then regardless of the any MUST-IMPLEMENT language in the spec, we'd
> move to disable it to protect our users. And I suspect other browsers
> would do the same. So that's why I think any MUST-IMPLEMENT language
> is non-binding.
>
> "Recommended" algorithms are both fine and a good thing, and I don't
> think there will be much of any debate about adding new algorithms to
> recommended - but must-implement feels like a reach.
>
> Cheers,
> Ryan
>
>>
>>
>> On 7/10/12 11: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].

I think that in general, we should have some subset (the JOSE subset 
seems the obvious and ideal candidate) as a SHOULD implement. If all we 
have is a discovery algorithm, then I can not see how we will create 
test-cases that are meanginful and that Web developers can rely on. We 
need to be able to say, for a given browser X, it supports this 
functionality as embodied in test-cases. Now, if a browser *only* throws 
errors, then obviously that is useless, but we don't want that 
technically passing the test-cases. We want to say that's non-conforming.

On the same-hand, I can see real value in having some generic extensible 
framework, of which I see this discovery mechanism as one way of 
approaching. I'm wondering if there any other alternative approaches?
>>
>> 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.

We will need to implement error handling to go to the next stage of W3C 
process after Draft, BTW, as otherwise we won't have consistent 
test-cases. That could be 'not bother' I assume, but I could also see a 
good case for giving more informative error messages. Whether or not 
that requires discovery is still I think a bit up in the air, I think 
there may be some cross-wired as regards what discovery means.
>>
>> [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 20:17:07 UTC