- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 11 Jul 2012 18:08:09 -0700
- To: Harry Halpin <hhalpin@w3.org>
- Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>, Mike Jones <Michael.Jones@microsoft.com>
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