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

On Wed, Jul 11, 2012 at 4:08 PM, Harry Halpin <hhalpin@w3.org> wrote:
> On 07/11/2012 12:03 AM, Ryan Sleevi wrote:
>>
>> On Tue, Jul 10, 2012 at 1:52 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>> On 07/10/2012 10:36 PM, Ryan Sleevi wrote:
>>>>>
>>>>> 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?
>>>>
>>>> Harry,
>>>>
>>>> I'm not sure I understand why this is required. For example, how are
>>>> test cases for the <video> tag covered, or <object>, or <img> or any
>>>> of the other hyper-media tags?
>>>
>>>
>>> Note that HTML is a bit special, due to its legacy status. However, the
>>> W3C
>>> is working on test-cases to get HTML5 to the next level of W3C Process.
>>> In
>>> general, we have to imagine "what is that we will test"?
>>>
>>> Again, this is a hard question. The WebApps WG is using this process [1],
>>> and now there is the WebDriver work at W3C which I suggest we use [2].
>>
>> Ok, I'll use a set of different examples then that may be more
>> reflective of the modern HTML5 design.
>
>
> These are good examples (although DAP is mixed success to uneven
> implementation, something I'd like us to avoid).
>
> However, here is a good example to illustrate my point: HTML5 Keygen, which
> comes up now and again.  The HTML5 spec requires browsers to support the
> keygen element but does not require them to fully implement it. Browsers are
> required to treat it as a known element  (due to effects on the DOM) and
> provide the HTMLKeygenElement interface, but they are not required to
> implement any key particular types/signature algorithms. If the browser
> fails to implement any key types/signature algorithms for keygen,then there
> is no real keygen element effect in that browser, as is the case for IE
> currently (for good reasons that IE has argued I think).


Your example of the HTMLKeygenElement is equally applicable to why I
don't want MUST-IMPLEMENT. The <keygen> tag, in addition to lacking
extensibility, mandates implementations MUST support known-weak
algorithms (md5WithRsa). Further, because it was documented for
'historical' reasons, there is active opposition towards improving
this - it would both break legacy deployed applications and require
more implementation effort.


> Thus, WebApp
> developers, as they cannot trust that keygen will be implemented
> cross-browser, do not use it. Do we want that to be the case for the Web
> Crypto API? I was hoping on an API with a sane implemented subset, based not
> on new coding but exposing existing code ala NSS, would be something that
> WebApp developers could depend on.

I don't believe that "Use NSS" is an acceptable standard for W3C
acceptance, as shown through the dissolution of the WebSQL standard.

Further, using NSS as an example, NSS as used in Chrome and Firefox
does not presume any particular subset of algorithms implemented. NSS
simply defines the "high-level" (as far as such native APIs concerned,
but more akin to our low-level API here) interface. It provides a
consistent interface (PKCS#11) for applications to provide
cryptographic functionality.

While it does ship with a software module that provides a number of
standard algorithms, that software module is exposed to NSS as "just
another module" and can be removed by users or system administrators.
There is no guarantee that an NSS-using application will have, for
example, the ability to compute a SHA-1 hash.

The same is true for CNG, Microsoft's API. CNG defines the core API.
Microsoft also ships default algorithm providers that plug in to the
CNG extensibility points. There is no guarantee that the Microsoft
shipped cryptographic providers will always be available.
Administrators can remove, replace, or reprioritize providers at will.

I would like to think that a user-agent that wished to ship no
built-in crypto, and instead use various industry-standard APIs
(PKCS#11, CDSA, CNG, etc), should be able to implement this standard.
With a MUST-IMPLEMENT, there is no 'guaranteed' way for a user-agent
to say that - and certainly, not to the satisfaction of web pages,
which has consistently been given as the example here of why
'MUST-IMPLEMENT' is valuable.

>
>
>>
>> Gamepad APIs:
>> - window.gamepads.length == 0 if there is no hardware support for a
>> Gamepad. Thus, conformance to the API cannot be tested without
>> supporting a physical gamepad. However, an implementation could fully
>> support what the spec says - it just doesn't have any hardware devices
>> connected.
>>
>> Geolocation API
>> - It does not require that implementations support GPS over, say, Wifi
>> sourced data - or even user input. It simply specifies how the API
>> would behave if position information was available.
>> - If geolocation is not supported, it will invoke the errorCallback
>> with a positionError. Further, there is no requirement that the
>> geolocation API provide meaningful information in the information it
>> returns.
>>
>> Device APIs:
>> Vibration API
>>   - An implementation can fully implement the Vibration API, raising
>> NotSupportedErrors whenever window.vibrate is called. It will be a
>> conforming implementation to do so.
>> Contacts API
>> - An implementation may fully implement the contacts API without
>> exposing any contacts.
>> MediaStream API
>> - Places no requirements on the interpretation of the binary data
>> provided by the MediaStream/MediaStreamTrack object
>>
>>>> For example, I'm not sure why we cannot detach the "API specification"
>>>> (these are the state machines, these are the error handling routines)
>>>> from "Algorithm specification" (this is how RSA-OAEP behaves, this is
>>>> how AES-GCM behaves).
>>>
>>>
>>> In general, with specs is better to have everything in one document
>>> unless
>>> document becomes unwieldy (for example, many people complained about XML
>>> namespaces not being part of the XML the spec). However, there are
>>> examples
>>> of W3C specs that *should* have been split into multiple documents (XML
>>> Schema Structures comes to mind).
>>
>> Sure, but as you've discussed on past calls, it's perfectly acceptable
>> to think of them as logically separate.
>>
>> Note that I'm absolutely in support of the WG's work product including
>> definitions of how 'common' algorithms should and will behave -
>> RSA-OAEP, RSA-PSS, HMAC, AES, etc . I'm absolutely in support of
>> saying "If you are going to implement this algorithm, this is how it
>> MUST behave.". What I'm concerned about is saying either of "You may
>> not implement any algorithm that is not specified" or "You MUST
>> implement these algorithms"
>
>
> How about "SHOULD", but error-handling defined consistently just-in-case?

That's 100% what I'm in favour of. "RECOMMENDED"/"SHOULD" or "MAY"

>
>>
>>>> Test cases for the API specification can focus on the objects having
>>>> the correct types / methods, the exception types existing, and any
>>>> user interaction.
>>>
>>>
>>> I agree with the first two, although if we have correct types/methods its
>>> generally useful to have a result we can check outside of an error
>>> message
>>> for some (possibly minimal) part of the spec. Generally, user *interface*
>>> is
>>> outside of test-cases, but kinds of interaction may be inside test-cases
>>> if
>>> necessary to test a feature of the API.
>>>
>>>> For algorithm specifications, it can test individual algorithm handling.
>>>>
>>>> However, for error handling, it seems like some tests will not be able
>>>> to be programatically simulating by a test suite, and must be
>>>> manually/synthetically simulated. For example, how might you test a
>>>> system failure between .processData() and .complete(), to ensure that
>>>> onerror is raised appropriately.
>>>
>>>
>>> Usually the test-cases are not as rigorous as say, production test-cases
>>> or
>>> full-scale state simulations done in a formal manner. W3C test-cases
>>> assume
>>> a normal operating environment without systems failures. We will likely
>>> not
>>> to simulations.
>>>
>>>> Beyond ensuring IDL conformance, I would think all tests can belong to
>>>> the algorithms - that is, IF a user agent implements RSA, here's tests
>>>> 1-15, to ensure it implements the "correct" form of RSA. IF a user
>>>> agent does not, it automatically passes that test suite/that suite is
>>>> not-applicable.
>>>
>>>
>>> I still am worried a browser can implement basically nothing and still
>>> pass
>>> the test-cases. The conformance is judged as regards the entire spec.
>>> However, we can clearly delineate which parts of the spec are SHOULD
>>> implement and which parts are OPTIONAL. That is quite useful. I am
>>> worried
>>> about all algorithms being OPTIONAL in theory, even if that seems to be
>>> an
>>> extremer. Again, I think having a subset of guaranteed algorithms (with
>>> *perhaps* a well-agreed upon deprecation method) and an extensible
>>> framework
>>> (of which the discovery algorithm the only proposal standing so far)
>>> makes
>>> sense.
>>
>> Ah, this may be where the disconnect is. I think it should be
>> perfectly acceptable for a browser to do this - that is, implement the
>> API without supporting a SINGLE algorithm - returning errors for all
>> attempts.
>>
>> Here's the reasoning for why I take this position:
>>
>> Cryptography, unlike many other software implementations, is something
>> that is very frequently controlled by regulatory bodies. While things
>> are nowhere near as problematic as they were in the 90s, any vendor in
>> the US that wishes to ship a product with a cryptographic
>> implementation will, at the least, be required to go through EAR
>> requirements via the US Department of Commerce. Similar requirements
>> exist for other countries participating in the Wassenaar Agreement.
>>
>> Mandating a MUST implement means that any conforming user-agent MUST
>> now be subject to these requirements and appropriate declarations. I
>> believe that such stipulation is akin (but not identical) to requiring
>> that implementations MUST implement some functionality that is
>> governed by patents - something that the W3C rightly avoids via its
>> patent policy.
>
>
> We'd want any SHOULD implements to be patent free. I know this is not the
> case, and there is govt. controversy, over well-known ECC. However, is the
> case for JOSE's defaults?

To be clear: My point here was to point that strict government control
(crypto as 'munitions' and the like) is a very similar space to
'patents'. Just as patents have strong government protections and
restrictions on use, so does crypto. So we should equally tread very
carefully.

>
>
>>
>> Today (that is, outside of the discussion of this particular API), and
>> keeping in mind this is far from legal advice, applications may be
>> able to avoid the EAR requirements by making use of cryptography
>> either part of the operating environment or via some other interface
>> (for example, hardware). Depending on how they use it, they may not be
>> subject to the requirements.
>>
>> Additionally, cryptographic implementations may be subject to various
>> government or business regulatory concerns. For example, FIPS 140-2
>> governs the use of cryptography within the US Government (along with
>> various other regulations requiring an implementation MUST be FIPS
>> 140-2 certified). A FIPS 140-2 compliant implementation MUST NOT use
>> certain algorithms / key sizes / etc. These regulations vary from
>> country to country - and some countries may mandate MUST IMPLEMENT for
>> other additional algorithms (GOST, SEED).
>
>
> I see no problem here, adding more is never a problem :) The only problem
> would be if some of the default JOSE algs were SHOULD NOT implement. But
> that's fine, the browser would just have to disable those for those
> use-cases and not support the Crypto API for generic WebApps.

PKCS1-V1_5, which is REQUIRED for JOSE, but for many cryptographers,
is arguably at best a MAY, but practically a SHOULD NOT.

Even RSA, via PKCS#1 2.0/2.1 / RFC 3447 has been advocating that
PKCS1-v1_5 is "included only for compatibility with existing
applications, and is not recommended for new applications". (Section
7). That has been the advice since 1998 - with RFC 2437.

>
>>
>> Again, applications can often avoid these potentially onerous
>> requirements by delegating the use of crypto to operating system APIs
>> or hardware.
>>
>> Finally, implementing crypto is hard. Really hard. We've already seen
>> examples on the list where subtle issues such as timing can undermine
>> the entire implementation. For security reasons, it's very much
>> preferable to delegate out - again, to the operating system,
>> third-party libraries, or hardware. Something that is stable, well
>> tested, and centrally updatable.
>
>
> See point re NSS. Again, I think we should minimize *new* implementation
> work on the crypto level, and we expect that most of these JS calls will be
> delegated out, with the JS providing an interface to NSS, Windows CryptoAPI,
> etc.

I think you may have missed my point. Putting MUST-IMPLEMENT is very
much an argument in favour of new implementations, as there is no
innate guarantee of what NSS/CryptoAPI/CNG/CSSM will implement. So the
only way a conforming user-agent will be able to fully implement the
standard, by truly implementing everything that is MUST-IMPLEMENT,
they would have to write new cryptographic implementations independent
of these and directly embed them in their application. That sort of
requirement is unacceptable.

>
>
>>
>>
>> If you look at the State of the Art of modern cryptographic APIs, they
>> are designed around a "module" concept. The API specifications
>> /simply/ provide a definition of how the APIs will behave and /may/
>> specify how specific algorithms (AES, RSA, OAEP, etc) may behave.
>> These APIs do NOT typically mandate innate support for any particular
>> algorithms. Conceptually, these APIs think of everything as "hardware"
>> (or "module", or "token", or "library", but same aggregation).
>>
>> Now, for utility, vendors /may/ ship software implementations - either
>> with the OS or with their library. But they /regularly/ give
>> administrators the ability to disable parts of such software
>> implementations - or even outright remove or replace them.
>>
>> In the straw-man, rather than expose this concept of "modules", which
>> varies in detail and functionality from implementation, I proposed
>> that the API be associated based on the concept of "keys". That is,
>> there is no requirement in which "module" a key is stored, nor is even
>> the concept of modules exposed to the consumer of the API. Instead,
>> the API exposes keys - of which the total set of available keys may
>> span multiple modules.
>>
>> For these reasons, any User Agent that wishes to operate in these
>> environments has NO guarantee about what the environment may or may
>> not support, short of re-implementing an entire cryptographic stack
>> for all of the MUST implements. I believe that, categorically, such a
>> requirement would REDUCE the security of users of this API, because
>> again, crypto is "hard".
>>
>> Thus, when I think of this API, I think of it as working with a
>> particular type of hardware device, much like Gamepad, Geolocation, or
>> MediaStream. There MAY be ways to emulate these devices via software
>> (A virtual gamepad might be emulated via a keyboard, a virtual GPS may
>> be emulated via Wifi location settings, a virtual video capture device
>> may be emulated by reading from a file on disk), but there is no
>> requirement that implementations MUST do so.
>>
>> This is part of why I'm so opposed to MUST-IMPLEMENT. User Agents that
>> wish to defer cryptographic implementations to their operating
>> environment (which itself may be backed by hardware) have no ability
>> to know what the operating environment may provide. As such, they
>> CANNOT guarantee that they're able to implement all of it, short of
>> shipping with their own cryptographic implementations, which then
>> opens a huge morass of governmental and regulatory concerns.
>>
>> For example, when running on Linux, Google Chrome and Mozilla Firefox
>> have no guarantees what cryptographic primitives will be available to
>> it. This can affect everything using crypto - most notably, SSL/TLS -
>> but that's perfectly acceptable and is something that is the
>> responsibility of the user. Chrome & Firefox simply consume the
>> standard cryptographic APIs (in this case, we're both using PKCS#11).
>> As such, it's impossible to fairly test that we implement all of the
>> MUST SUPPORT algorithms, if there were any.
>
>
> Again, this is where I disagree. CA problems aside, I think a user should by
> default not have to care about if their browser actually implements safe
> SSL/TLS, but that this is a responsibility of the app developers and
> browsers. The API should allow people to use these algorithms safely and
> reliably, and if they aren't reliable, I'm worried no-one will use ala
> keygen.
>
> Heck, we can't even get users to look at the "lock" icon :)
>
>>
>>>> I was also hoping you could explain the statement: " 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."
>>>>
>>>> Why?
>
>
> See above argumentation. I respect and understand your viewpoint, it just
> worries me to some extent that we may produce an API that people won't
> reliably be able to use and that we can have null test-cases for while still
> being technically conformant.
>
>
>>>
>>> As that browser would have no functionality that a web developer could
>>> use
>>> as regards this API other than produce the correct "not supported"
>>> errors.
>>> Its an edge-case, but could happen!
>>>
>>> [1] http://www.w3.org/2008/webapps/wiki/Harness
>>> [2] http://www.w3.org/TR/webdriver/
>
>
>

Received on Wednesday, 11 July 2012 23:35:07 UTC