- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 6 Aug 2011 15:37:53 +0200
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: David Dahl <ddahl@mozilla.com>, public-identity@w3.org
On 6 Aug 2011, at 15:19, Anders Rundgren wrote: > I find Google's answer puzzling. Clearing the browser's TLS cache is > pretty unrelated to cryptographic APIs like DomCrypto. I see it > more like a "workaround" since there should be a way to "signal" > logout from the server using TLS. the good news is that from the bug report they are working on a C api for that. > HttpSession.invalidate () doesn't work at all as one expects it to do. Well one would not expect http session invalidation to disable TLS Sessions. But perhaps there should be a more general IdentitySession.logout that would do the right thing. But really that should be be built into the browser chrome, completely inaccessible from the web sites. (This is not to say that one cannot also have a javascript logout mechanism, as a paliative, just that the chrome would override all other behaviour) Henry > Anders > > On 2011-08-06 13:16, Henry Story wrote: >> Hi, >> >> I have been looking at how a client can logout from a TLS session recently, so that if a user >> sends the wrong certificate to the server, the server can propose a way for the user to choose a >> different one. >> >> The correct way to do this would be to build it right into the browser, so that at all times the user is in control of his Persona, i.e. to extend Aza Raskin's work to the TLS layer [1]. >> >> The second best way is to have a Javascript API to logout the user, that web page authors can use to offer this feature. Firefox and Internet explorer have such an API. The Firefox one is described in the WebCrypto API [2] by Channy Yun, which was discussed on this list recently. >> >> The code to run both in IE and Firefox is quite simple. I submitted a bug report to Chrome with the >> code to suggest that they could implement this there too >> >> http://code.google.com/p/chromium/issues/detail?id=90676 >> >> But they want the DOMCrypt spec approval before implementing. Is that something that could be added to DOMCrypt? Or should one look somewhere else? >> >> This is a really simple function, but it is so useful. >> >> Henry >> >> >> [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ >> [2] http://html5.creation.net/webcrypto-api/ >> (the login method does not work currently in Firefox, on has to use logout, where the connection then asks the client for a certificate) >> >> >> >> >> >> On 20 May 2011, at 17:04, David Dahl wrote: >> >>> Hello WHATWG members, >>> >>> With user control and privacy in mind, I have created a spec and an implementation for an easy to use cryptography API called DOMCrypt. This API will provide each web browser window with a 'cipher' property that facilitates: >>> >>> * asymmetric encryption key pair generation >>> * public key encryption >>> * decryption >>> * signature generation >>> * signature verification >>> * hashing >>> * easy public key discovery via meta tags >>> >>> I have created a Firefox extension that implements all of the above, and am working on an experimental patch that integrates this API into Firefox. >>> >>> The draft spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >>> >>> 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 >>> >>> You can test the API by installing the extension hosted at domcrypt.org and addons.mozilla.org, and going to http://domcrypt.org >>> >>> Best Regards, >>> >>> David Dahl >>> >>> Firefox Engineer, Mozilla Corp. >> >> Social Web Architect >> http://bblfish.net/ >> >> >> > Social Web Architect http://bblfish.net/
Received on Saturday, 6 August 2011 13:38:40 UTC