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

On 07/12/2012 03:08 AM, Ryan Sleevi wrote:
> On Wed, Jul 11, 2012 at 5:23 PM, Harry Halpin <hhalpin@w3.org> wrote:
>> 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; 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> 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.
>>
>>
>> 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
> Harry,
>
> I think the above sounds good.
>
> Several comments below on the specific details of how it might work,
> but perhaps that should be spun up into a new ISSUE regarding
> testing/CR advancement? Or is this much too early to begin worrying
> about that?

It's a bit early, but its always good to keep in mind. Once we get some 
parts of the design nailed down, I'd say start immediately with 
test-cases if possible.
>
>
> I think I'd go a step further and suggest that every algorithm we
> specify (SHOULD or MAY) should have a set of test cases associated
> with it.


Yes, I agree that every feature should have a test-case. What I was just 
trying to figure out is how we define the minimal definition for 
interoperability of the spec, if we have a generic and extensible 
framework and no MUST-IMPLEMENTs.

Also, we need this minimal definition for interop on test-cases (the at 
least two SHOULD algorithms, with no MUST-IMPLEMENT algorithms) can be 
time-consuming, so its possible that just for timing/schedule reasons we 
won't make test-cases for every feature.
>
> These test cases should likely cover:
> ** That the API behaves consistently (eg: dictionary parameters are
> handled, error handling for invalid inputs, etc)
> ** That the API produces consistent outputs for consistent inputs (ie:
> Known Answer Tests). This is specifically to cover implementations
> that may yield incompatible byte sequences (eg: little-endian
> signatures produced by CryptoAPI vs the big-endian signatures produced
> by almost every other API). It may also be used to ensure that
> algorithms behave the same with regards to invalid inputs (eg: invalid
> PKCS#1 padding bytes). This may be a prickly point though, so I'm not
> sure how well this will go over.
>
> This will ensure that any algorithm we specify as standardized, even
> just as a SHOULD implement, MUST behave the same way consistently if
> it is implemented by a UA. I don't think we'd want to spec out a
> single algorithm that did not behave consistently between UAs that
> claimed to implement it.
+1
>
> Of course, that opens a new can of worms: Even at the algorithm level,
> are there MUST features? For example, for RSA-PSS, MUST you support
> RSA-1024, RSA-2048, RSA-4096, etc? Or is it again another case of
> SHOULD, with a set of KAT/test cases for certain
> combinations/parameters if you DO?

I think this should be considered on a per algorithm basis, and thus 
picking the minimal set of two or more to SHOULD implement is important. 
Obviously, doing this for a small set is fine, going for a huge set may 
never be finish.
>
> Further, for a single UA that may leverage multiple crypto backends
> (eg: NSS, CNG, CDSA), does that count as "one implementation" or
> "three implementations"? At an algorithm layer, it's likely 3 - but at
> an API/bindings layer, it's likely 1.

Generally, we'd count each JS programming environment (read "browser" 
but bigger) as a different implementation even if they use the same 
backend.
>
> Finally, to standardize the API itself, should there be any
> requirement on the number of compatible/interoperable implementations?

Yes, we need at least two implementations according to standard W3C 
process. More is better though, and the rest of W3C will look at our 
interop factor when CR comes. That we should probably not fret over too 
much at this point, but again, keep in mind.
> How would this be quantified? Just that two implementations exist that
> pass the algorithm tests? That two implementations exist with the same
> subset of algorithms? For example, 2 U-As (Browser A, Browser B)
> implement two algorithms (A = 1,2 , B = 3,4). That's four total
> algorithms implemented, each with only one API implementation, but
> possibly three different underlying crypto implementations.

We'd count the U-As. Perhaps this isn't right for this kind of work, but 
we'd want at least (A = 1,2 and B = 1,2), although again, (A=1,2 and B= 
1,2,3,4) is fine!

>
> What if A/B both implemented the same algorithms (1, 2), but A
> implemented at key sizes > 4096, while B implemented at key sizes <
> 4096?

That would likely not count off the top of my head, but happy to hear WG 
discuss.

    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/
>>
>>
>>
>>
>>

Received on Thursday, 12 July 2012 05:34:24 UTC