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

>>To me the real value of MUST-IMPLEMENT is that if something on the MUST-IMPLEMENT list fails a programmer can tell the user that they have an
>>unusual configuration and should try to fix that. The programmer still needs to fail gracefully but they can limit their test matrix. This is a worthy goal and
>>I have no problem with it as long as we message it properly.

I agree with this. I have come to realize that we are treating a MUST-IMPLEMENT as suggesting that this list is the ONLY SAFE list for developers to choose from. That definitely is NOT the intention. The intention is to get the developers going as quickly as possible with as minimum effort as possible. The onus is still on the developers (or the security architects in their organizations) to choose wisely.

Regarding failing gracefully (good programming practice), I stated earlier that the problem is not with catching exceptions, but for developers it is a question of what goes into those catch blocks. The question is whether they treat it as 'unusual' situation or a 'normal' situation.


On 7/11/12 6:41 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:

I don’t object to a SHOULD-IMPLEMENT. I would go further – I would be fine with “MUST be possible to configure with support for” or even “MUST IMPLEMENT in its default configuration”.

To me the real value of MUST-IMPLEMENT is that if something on the MUST-IMPLEMENT list fails a programmer can tell the user that they have an unusual configuration and should try to fix that. The programmer still needs to fail gracefully but they can limit their test matrix. This is a worthy goal and I have no problem with it as long as we message it properly.

From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Wednesday, July 11, 2012 5:24 PM
To: Vijay Bharadwaj
Cc: Ryan Sleevi; Seetharama Rao Durbha; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; David Dahl; Mike Jones
Subject: Re: ISSUE-1: Mandatory algorithms (was Re: ISSUE-3: Algorithm discovery)

On 07/12/2012 01:59 AM, Vijay Bharadwaj wrote:

+1



Much as a MUST-IMPLEMENT core algorithm set would be nice, it seems like it would tie compliance to the U-A environment (specifically, as Ryan mentions below, tying the browser's compliance to the OS configuration). Are there other examples where W3C has tied compliance to the environment in this way?



-----Original Message-----

From: Ryan Sleevi [mailto:sleevi@google.com]

Sent: Wednesday, July 11, 2012 4:35 PM

To: Harry Halpin

Cc: Seetharama Rao Durbha; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; David Dahl; Mike Jones

Subject: 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><mailto: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><mailto: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.

As pointed out by Mike Jones, the answer is to have a clear registry. Re-using the JOSE one is one proposal.








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.
Note that I have always been neutral as regards MUST-IMPLEMENT and SHOULD.

I'm worried over only MAY implement, for the reason that I just want to see *something* work in the API besides error messages and that I'm not sure if I can honestly say that two or more inter-operable implementations of just error messages is enough to get us past Candidate Rec stage. Those less technically involved in the details within industry and the W3C may be skeptical of the interop benefits of standardization in that case. For this reason, previous W3C WGs in this area such as XMLDSIG and XMLENC both have at least *two* independent mandatory-to-implement algorithms when possible, in case one breaks during the life of standard. While I'm not really worried about MUST vs. SHOULD, I'm worried about test-cases and getting to CR.

So, I think we can agree:

1) Having a common subset of algorithms that we can test, and thus achieve CR status, is useful and developers will need such assurances at least for increasing adoption of the API.

2) A MUST-IMPLEMENT is for various reasons argued on the mailing list is a bad idea.

 Thus, I propose that we resolve this issue by doing a much weaker version of what XML-DSIG and XML-ENC did, to have no MUST IMPLEMENT but instead a recommended SHOULD implement. The WebCrypto API should have a subset (at least two or more) of recommended algorithms that we build test-cases along to move to CR, but no strict conformance testing that requires a MUST-IMPLEMENT, as we recognize those algorithms may change and are use-case dependent.  Thus, there will be *no* MUST-IMPLEMENT, but recommended SHOULD implement.

Is that weaker stance as regards recommended algorithms with test-cases also being objected to, or are we happier with that?


   cheers,
     harry













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/