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.