- From: David Dahl <ddahl@mozilla.com>
- Date: Thu, 22 Sep 2011 08:05:02 -0700 (PDT)
- To: John Kemp <john@jkemp.net>
- Cc: Henry Story <henry.story@bblfish.net>, public-identity@w3.org
----- Original Message ----- > From: "John Kemp" <john@jkemp.net> > To: "David Dahl" <ddahl@mozilla.com> > Cc: "Henry Story" <henry.story@bblfish.net>, public-identity@w3.org > Sent: Wednesday, September 21, 2011 9:33:35 PM > Is the private key private to the client or to origin A? Is the server > merely instructing the client on which key (generated based on > instruction from the server) to use when encrypting data sent to its > own origin? In other words is the server asking the client to use > origin A's key to encrypt data from the client to origin A? > The private keys are always private to the client for the origin per origin. For every site you use with DOMCrypt you will have a unique set of keys. The script has no access to them. The only time you handle any kind of key material is when the keypair is created, and even then you are only handed back the public key. > I think the gist of the Matasano blog post (this is my interpretation > anyway) is that you can given them (Javascript developers) these > things and it doesn't solve the essential problem of trust between > client and server. In other words, it is still possible for an MITM to > make the client believe it is interacting with a trustworthy entity, > in which case, the encryption part itself is very much less useful. > Or, at least, it is no more useful than SSL/TLS. Indeed. DOMCrypt is not a solution guaranteeing trust between browsers and web servers. That is a non-goal. Cheers, David
Received on Thursday, 22 September 2011 15:05:40 UTC