On Thu, February 14, 2013 11:55 am, John Dennis wrote: > On 02/14/2013 02:34 PM, Ryan Sleevi wrote: > > On Thu, February 14, 2013 10:43 am, Robert Relyea wrote: > >> On 02/14/2013 07:54 AM, David Dahl wrote: > >>> ----- Original Message ----- > >>>> From: "Gervase Markham"<g...@mozilla.org> > >>>> To: mozilla-dev-tech-cry...@lists.mozilla.org > >>>> Cc: "Eric Rescorla"<e...@mozilla.com>, "Brian > >>>> Smith"<bsm...@mozilla.com>, "Brendan Eich"<bren...@mozilla.com>, "Ben > >>>> Adida"<benad...@mozilla.com>, "Brian Warner"<war...@mozilla.com> > >>>> Sent: Thursday, February 14, 2013 5:22:41 AM > >>>> Subject: Re: Web Crypto API(s) and what Mozilla wants / needs > >>>> > >>>> On 13/02/13 20:55, David Dahl wrote: > >>>>> The main issue is: What does Mozilla actually need here? What is > >>>>> Mozilla's official policy or thinking on a crypto API for the DOM? > >>>> As you are the Mozillian with most experience in this area, I'd say > >>>> that > >>>> insofar as we will ever have an official policy, it's likely to be > >>>> "what > >>>> you think" (after taking the input of others, as you are doing). > >>>> Please > >>>> feel empowered :-) > >>> Ah, thanks! I am however, not a 'crypto expert' and would like the > >>> actual experts to weigh in and set the 'policy' (for lack of a better > >>> word.) At this point in the game, it would seem that FirefoxOS, with > >>> it's enhanced security model, would benefit greatly from APIs like > >>> this. > >>> I am hoping that will help in garnering the resources to implement > >>> and/or develop an engineering schedule for this. > >>> > >>> -david > >> Well, I am quite pleased with the approach of providing a limited > >> controllable set of primitives that are easy to use. The encrypt/sign > >> - > >> decrypt/verify using PKI completely sounds like the right first > >> primitive to supply, along with seal/unseal. Key management/key > >> exchange > >> is the hardest part to get right in crypto. Both of these provide the > >> simplest model for managing these things. > > > > Agreed on key management/key exchange. Note that the current proposal > > intentionally largely tries to avoid these matters, for that reason. > > Instead, it operates on the presumption that the user has a Key object, > > and the question is what operations can be performed with it. > > > >> > >> I'm sure there are lots of applications where these primitives are > >> insufficient, but enabling a stable set that is easy for the > >> non-crypto > >> person to get right definately sounds like the right way to move > >> forward. (Both of these also has the advantage of allowing you to > >> define > >> API's where algorithm selection can be automatic, meaning the users > >> automatically get new algorithm support without having to change the > >> javascript application. > > > > Bob, > > > > As you mentioned, there are lots of applications where these primitives > > are insufficient. Certainly, NSS would not be in usable today for > > Firefox > > or Chromium if it adopted only the high-level approach being proposed > > (and > > as reflected in APIs like KeyCzar and NaCL). Likewise, NSS's > > highest-level > > APIs (like S/MIME) go largely unmaintained/unused, while the low-level > > crypto is used in a variety of projects (as shown at the sheer number of > > packages converted at > > http://fedoraproject.org/wiki/FedoraCryptoConsolidation ). > > > > Do you know of any applications where they *would* be sufficient? Do you > > anticipate non-crypto people to be able to use 'crypto', even > > high-level, > > for the development of an overall secure system? I'm aware of the > > arguments made in http://cr.yp.to/highspeed/coolnacl-20120725.pdf , and > > I > > certainly support a high-level API, but I don't think you avoid any of > > the > > thorny issues (algorithm negotiation, wire format, etc), and I'm not > > sure > > that the high-level API makes the overall *application* any more or less > > secure than a low-level API using recognized primitives. > > > > I guess it's my way of suggesting I'm more concerned about the places > > where "these primitives are insufficient", and I'm less convinced of the > > idea that it any more easier "for the non-crypto person to get right". > > Given your long-standing role in NSS, I'm curious your thoughts on the > > types of applications that would be able to actually (and successfully, > > and securely) use such an API. > > Sorry to butt in on a question directed to Bob, but ... > > Here's one data point. I constantly hear the complaint from developers > that NSS is too low level and using it is too hard. They wonder why > there can't be a higher level API that insulates them from many of the > quirky details they find somewhat incomprehensible leaving them with > doubts about the correctness of what they've done and dismayed at the > time it took to accomplish it. > > So yes, I think higher level API's would be welcome. I also think it > would be welcome if the high level API interfaces permitted swapping out > the low level crypto library on which they are based. Why? It's not > unusual for someone with a problem to be asked, can you use X, Y, or Z > instead and tell me if you still have the issue. That's a non-starter > for many applications unless they had the foresight to implement > "pluggable crypto", and I'm only aware of a handful of those, usually > they've hitched their horse to one implementation. >
John, Surely you're not suggesting that arbitrary web applications be able to use JavaScript to swap out the crypto library used by the browser? 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 (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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
