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 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
