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 <ddahl@mozilla.com?Subject=Re%3A%20Request%20for%20feedback%3A%20DOMCrypt%20API%20proposal&In-Reply-To=%253C4DEC6519.2070801%40telia.com%253E&References=%253C4DEC6519.2070801%40telia.com%253E>> 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.
>
>  I'm with Anders, we should flush out a well-thought user story first and
see what the target use cases are (specifically WRT key management and
consumption).  I'm good with seeing a v1 be simplified and inherently secure
by scoping its usage to same-origin 100%, and do a sibling spec later for
cross-origin & device key sharing.  Just a thought...

>
>
> 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 <anders.rundgren@telia.com?Subject=Re%3A%20Request%20for%20feedback%3A%20DOMCrypt%20API%20proposal&In-Reply-To=%253C4DEC6519.2070801%40telia.com%253E&References=%253C4DEC6519.2070801%40telia.com%253E>>
> >> To: "David Dahl" <ddahl@mozilla.com <ddahl@mozilla.com?Subject=Re%3A%20Request%20for%20feedback%3A%20DOMCrypt%20API%20proposal&In-Reply-To=%253C4DEC6519.2070801%40telia.com%253E&References=%253C4DEC6519.2070801%40telia.com%253E>>
> >> Cc: public-web-security@w3.org <public-web-security@w3.org?Subject=Re%3A%20Request%20for%20feedback%3A%20DOMCrypt%20API%20proposal&In-Reply-To=%253C4DEC6519.2070801%40telia.com%253E&References=%253C4DEC6519.2070801%40telia.com%253E>
> >> 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.
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
>


-- 
.................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>