Re: Request for feedback: DOMCrypt API proposal

On 2011-06-06 03:14, Adam Barth wrote:
> 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?

Well, here is the big decision-point.  Is this API dedicated for
keys that are store in the web environment only?  I.e. the API
does not have access to (for example) on smart cards?

> 
>> 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 couldn't deduct that from the specification but it is IMO the only way
ahead otherwise the whole thing will collapse on security issues!

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

SSL client certs will remain the most important PKI method because
DOMCrypt/web storage has huge limitations, particularly with respect
to credential mobility.  Payment credentials such a Google wallet
will be stored in SE (Security Elements) and unlikely be available
through DOMCrypt.

Don't get me wrong, but we are talking about two entirely different
use-cases.

Regards,
Anders


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