[whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

One thing that is covered in passing in the DOMCrypt spec is having the browser ask the user to whitelist pages or domains that can access public keys, key generation, addressbook or any other API method or data. I imagine this would be implemented much like way geolocation data access is handled. Perhaps I need to make it more clear.

Regards,

David

----- Original Message -----
From: "Mike Hanson" <mhanson at mozilla.com>
To: "Jonas Sicking" <jonas at sicking.cc>
Cc: whatwg at lists.whatwg.org, "=JeffH" <Jeff.Hodges at kingsmountain.com>
Sent: Monday, May 23, 2011 11:25:39 PM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

...

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