[whatwg] window.cipher HTML crypto API draft spec

[Mike Hanson]

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