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. Cheers, Ryan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
