[whatwg] window.cipher HTML crypto API draft spec
mhanson at mozilla.com
Mon May 23 21:25:39 PDT 2011
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.
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
>>> 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
>> The Need for a Web Security API
>> Wanted: Native JS Encryption
>> 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
> 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
>> 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
More information about the whatwg