- From: Mike Hanson <mhanson@mozilla.com>
- Date: Mon, 23 May 2011 21:25:39 -0700
The "Need for Web Security API" paper is a good intro - we'll be discussing it in the W3C Identity workshop tomorrow. I'll make sure this thread makes it into the requirements discussion. In talking with a couple people about it today, it became clear that there at least two, maybe three (or more), layers to a "browser-level crypto" API. The first level is math: fast, correct, FIPS 140-audited implementations of common crypto algorithms. Parser implementations might go in this bucket as well. The second is authority-granting: allowing web content to access keying material that resides outside of the content's usual purview, typically for integrity-protecting or authenticating purposes. This could be as simple as key material held outside of the content's access, or as complex as a hardware security module. PKCS11 will come up at some point in this conversation. Perhaps hardware randomness is in this bin. The third sort-of domain, is in level-crossing: think of providing access to SSL/TLS keys from content, as in RFC 5705. There are probably authority-granting cases here that I haven't thought of. This may not be a useful distinction. I suspect that it will be useful to lightly separate the "math" conversation from the "authority" conversation - they are both interesting but they probably involve different people and different concerns. -Mike On May 23, 2011, at 9:05 PM, Jonas Sicking wrote: > On Mon, May 23, 2011 at 8:14 PM, =JeffH <Jeff.Hodges at kingsmountain.com> wrote: >> David Dahl replied.. >>> >>> "Simon Heckmann" <simon at simonheckmann.de> asked.. >>> >>>> Why does it only handle asymmetric encryption? Something to >>>> encrypt/decrypt data with e.g. AES would be nice as well! >>> >>> I do need to add a symmetric encryption API as well, my current focus has >>> been on the exchange of message between web users, but that is only one >>> facet of the results of this effort. I should look at the big picture a >>> bit >>> and think about what that API should look like. >> >> Various folks have been thinking about the need to leverage platform crypto >> functions (rather than implementing crypto in "JS libraries") via a >> standardized API for browser-side web app code such that a >> swath of use cases is addressed, here's a couple examples of such position >> statements.. >> >> The Need for a Web Security API >> http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf >> >> Wanted: Native JS Encryption >> http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/ >> https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html >> >> Some have noted that there ought to be a very high level API built on top of >> such a substrate that web app developers could use for their more common use >> cases. Keyczar is one example of such an API <http://www.keyczar.org/>, and >> cryptlib is another >> <http://www.cryptlib.com/security-software/programming-code-examples>. > > Couldn't this high level API be the API that David is proposing? Or > are these threads calling for something even higher level? > >> Adam Barth replied.. >>> >>> David Dahl said.. >>> >>>> Yes, that is the case, I am using NSS. I imagine other browser vendors >>>> would also use NSS to implement this. >>> >>> It's very unlikely that Microsoft will use NSS to implement this API in >>> IE. >> >> Agreed. We nominally need an API that can be implemented by interfacing >> with NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL, >> GPG, OpenPGP, etc). > > The API David is proposing is looking generic enough to me that it > should be no problem implementing in libraries other than NSS. Do you > see any reason it wouldn't be? > > As a separate question, is anyone here familiar enough with keygen to > know if the proposed API could replace keygen? > > / Jonas
Received on Monday, 23 May 2011 21:25:39 UTC