[whatwg] window.cipher HTML crypto API draft spec

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:05:48 UTC