On 02/14/2013 03:19 PM, Ryan Sleevi wrote:
On Thu, February 14, 2013 11:55 am, John Dennis wrote:
Surely you're not suggesting that arbitrary web applications be able to use JavaScript to swap out the crypto library used by the browser?
Absolutely not from JavaScript. But as a browser config sure.
This is purely in the context of a Javascript API intended for both web applications AND extensions (or, in the case of B2G, B2G Apps). So there's a wide spectrum of possible applications that may be developed or wish to be developed. For example, would a B2G SSH be possible? ConnectBot is quite popular on Android - after all, AIUI, the NSS Android builds themselves rely on having an SSH app installed on the phone (Kai, is that a correct understanding?) Were you perhaps talking about a new C API for high-level crypto, that interops with multiple 'lower' level APIs
Yes that's where my thoughts were going. If high level Javascript as well as C/C++/Java/Python/Ruby etc. API's followed the same models, used the same terminology, names, and fundamental objects I think it would be a huge win.
It seems to me the current state of affairs is there is wealth of incompatible poorly written crypto API's across a range of languages and environments. Good API design is an art. Having a crypto guru write a crypto API for the masses is akin to asking a kernel developer to develop a friendly user interface, it's possible but not likely.
I think where I was going is if this effort could yield a simple, easy to use, easy to comprehend, easy to be secure API that serves 90% of the common use cases then I think it would have accomplished something we haven't achieved yet, and if so it can be a model to converge on. It would be something the whole software ecosystem would appreciate. I'd like to see a lot more focus on API design driven by usability requirements instead of driven by the underlying implementation.
A lot of effort has to go into developing abstractions while rigorously applying the simplicity test. I'm afraid committees have a poor track record in this regard FWIW. :-(
(if so, what APIs?). Arguably, NSS is itself a 'pluggable' crypto - everything in pk11wrap and higher is implemented in terms of PKCS#11 - that is, not directly talking to softoken, but speaking to generic PKCS#11 modules and slots, which are a standard abstraction for crypto modules/libraries.
Well, I think it might be a bit a stretch to call NSS pluggable, but I see where you're coming from. There is still a fair amount of ground not covered by PKCS11. I think one might be hard pressed to have a rich crypto environment while restricting yourself to only what's available via PKCS11, but your point is taken. Also PKCS11 is a bit long in the tooth by contemporary standards, but that's another topic.
-- John Dennis <jden...@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
