Re: Request for feedback: DOMCrypt API proposal

Anders:

This is a somewhat un-answered question if you look at the spec, which is undergoing a lot of editing right now. There absolutely must be some kind of UI that governs access to every method in this API. I imagine it will be much like the prompts that ask for user approval in GeoLocation. 

Another idea is treat keypairs similar to the data in localStorage where a script cannot use the API unless it has been granted access and it is with the keypair generated by the current origin only. 

I'm not sure we couldn't also have additional keypairs that the enduser could use for any operation with any origin, again, the UX/UI here will have to be elegant to keep people from doing the wrong thing.

Regards,

David

----- Original Message -----
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "David Dahl" <ddahl@mozilla.com>
Cc: public-web-security@w3.org
Sent: Sunday, June 5, 2011 2:52:29 AM
Subject: Re: Request for feedback: DOMCrypt API proposal

I have a question which I brought up in the "Identity in the Browser" WS:

If you do private/secret key operations that target keys that reside
in the platform, doesn't that require a GUI like crypto.signText()?

My experiences with Microsoft's "CertEnroll" indicates that exposing
platform crypto modules to untrusted browser code is a surefire way
of getting into trouble.

I don't see that statically installed ActiveX controls and JavaScript
are any different in this respect.

Anders

On 2011-06-02 15:46, David Dahl wrote:
> Hello public-web-security members,
> 
> (I wanted to post this proposed draft spec for the DOMCrypt API ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list - if there is a more fitting mailing list, please let me know)
> 
> I recently posted this draft spec for a crypto API for browsers to the whatwg (see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) and wanted to get feedback from W3C as well.
> 
> Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).
> 
> We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.
> 
> The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API.
> 
> This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:
> 
>     asymmetric encryption key pair generation
>     public key encryption
>     public key decryption
>     symmetric encryption
>     signature generation
>     signature verification
>     hashing
>     easy public key discovery via meta tags or an ‘addressbookentry’ tag
> 
> [1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto
> 
> I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.
> 
> The project originated in an extension I wrote, the home page is here: http://domcrypt.org
> 
> The source code for the extension is here: https://github.com/daviddahl/domcrypt
> 
> The Mozilla bugs are here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
> 
> Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
> 
> You can test the API by installing the extension hosted at domcrypt.org, and going to http://domcrypt.org
> 
> A recent blog post updating all of this is posted here: http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
> 
> The API:
> 
> window.cipher = {
>  // Public Key API
>  pk: {
>    set algorithm(algorithm){ },
>    get algorithm(){ },
> 
>   // Generate a keypair and then execute the callback function
>   generateKeypair: function ( function callback( aPublicKey ) { } ) {  },
> 
>   // encrypt a plainText
>   encrypt: function ( plainText, function callback (cipherMessageObject) ) {  } ) {  },
> 
>   // decrypt a cipherMessage
>   decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) {  },
> 
>   // sign a message
>   sign: function ( plainText, function callback ( signature ) { } ) {  },
> 
>   // verify a signature
>   verify: function ( signature, plainText, function callback ( boolean ) { } ) {  },
> 
>   // get the JSON cipherAddressbook
>   get addressbook() {},
> 
>   // make changes to the addressbook
>   saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) {  }
>   },
> 
>   // Symmetric Crypto API
>   sym: {
>   get algorithm(),
>   set algorithm(algorithm),
> 
>   // create a new symmetric key
>   generateKey: function (function callback ( key ){ }) {  },
> 
>   // encrypt some data
>   encrypt: function (plainText, key, function callback( cipherText ){ }) {  },
> 
>   // decrypt some data
>   decrypt: function (cipherText, key, function callback( plainText ) { }) {  },
>   },
> 
>   // hashing
>   hash: {
>     SHA256: function (function callback (hash){}) {  }
>   }
> }
> 
> Your feedback and criticism will be invaluable.
> 
> Best regards,
> 
> David Dahl
> 
> Firefox Engineer, Mozilla Corp.
> 
> 
> 
>

Received on Sunday, 5 June 2011 14:37:43 UTC