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

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?


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.

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.

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?

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.

Finally, to standardize the API itself, should there be any
requirement on the number of compatible/interoperable implementations?
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.

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?

>
>
>
>
> 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 01:08:38 UTC