Re: Suggestions on high-level API - perhaps a meeting next week?

On Mon, Sep 24, 2012 at 1:44 PM, Harry Halpin <hhalpin@w3.org> wrote:
> Looking at various discussions about the Web Crypto API, it seems that most
> of the concern is the "footgun" problem, i.e. we are giving developers a gun
> to shot themselves in the foot. Most of the concern seems to be over the JS
> environment as a whole, but there is considerable concern over the larger
> issues related to the Web Security Model (i.e. CSP.). I'll draft some text
> on how the Web Crypto API only solves a limited part of the problem (i.e.
> primitives for re-implementing existing work, random number generation, key
> storage). However, it would behoof us by our next WD release to actually
> *address* these concerns. The primary concern seems to be having a
> high-level APIs (which would require pushing on the discovery algorithm).
>
> Thus, my suggestion is that we start at least collecting examples of good
> high-level APIs and comparing their functions, and see if we can get a clear
> consensus. These three come up off top of my head:
>
> 1) DOMCrypt - This is David Dahl, who is one of co-editors and a member of
> our WG.
>
> 2) Stanford Crypto API - Dan Boneh, Mike Hamburg, and Emily Stark (who is on
> our WG)
>
> 3) KeyCzar - this is Steve Weis/Ben Laurie from Google. Shall we ping them?
> @Rsleevi and @wtc?
>
> We could get a call devoted to this topic, and maybe invite some of the
> folks that aren't in our WG. I'd be happy to go for this next week unless we
> want to prioritze other issues!
>
>    cheers,
>      harry
>
> [1] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> [2] http://crypto.stanford.edu/sjcl/
> [3] http://www.keyczar.org/
>

There is also NaCl (pronounced "salt") - http://nacl.cr.yp.to/ - Which
is Daniel J. Bernstein (djb), Tanja Lange, and Peter Schwabe.

However, the issue with SJCL, Keyczar, and NaCl is that they define
both APIs *and* message formats. That is, a message protected under
SJCL is not, AFAICT, exchangeable with a message protected under
keyczar.

As we discussed on our telecon today, and as raised by Mike Jones, it
seems equally appropriate that we point to and encourage the IETF JOSE
work, which is (presently) focused solely on a message format and not
on an API.

The issue with the "high-level API" is two-fold. The only way to
replace the footgun is to do the crypto for them, and if you're going
to do the crypto for them, it needs to be interoperable between user
agents. I think JOSE's message format does this much better, in terms
of public engagement and in addressing the cryptographic concerns,
that it may be suitable to instead look at the high level API as
perhaps simply an API for JOSE.

Received on Monday, 24 September 2012 20:53:39 UTC