Re: Request for feedback: DOMCrypt API proposal

On Sun, Jun 5, 2011 at 7:36 AM, David Dahl <ddahl@mozilla.com> wrote:
> 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.

I'm not sure I understand.  Why must there be UI?

> 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.

Right.  All state should be per-origin.  We don't want to repeat the
mistakes of SSL client certs!

Adam


> 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 Monday, 6 June 2011 01:15:51 UTC