- From: peter williams <home_pw@msn.com>
- Date: Sat, 12 Feb 2011 11:10:44 -0800
- CC: "'WebID Incubator Group WG'" <public-xg-webid@w3.org>
- Message-ID: <SNT143-ds13FDDFCB150D6097E0DE0792EE0@phx.gbl>
There are lots of ways to address it. The CCV is not limited to what is asserted (being RSA centric, in its presentation). There are many more approaches that leverage the properties of non RSA handshake designs. Without overloading folks, there is 50 years of debate on using crypto handshakes in two competing structures: one terms the trusted relay structure, the other termed the writer-to-reader structure. Billion dollar organizations with egos the size of the exhaustive searchspace for theoretical ciphers have argued for 50+ years on the topic. Makes the various incarnations of the format wars look puny. > Client Certificate Verify messages consist of a hash derived from the SSL/TLS handshake messages in the connection being established, signed by the client certificate's private key. With a MITM proxy the verify message will only be seen by the MITM, not the origin, and the MITM can't forward the signature to the origin since it would be negotiating a different session for which the signature would not verify. Ok, that makes sense. I can think of a solution here that can make WebIDs work for companies with a setup like this: The proxy when asked for a client certificate by the server the employee is trying to connect to could just make a similar request to the employee's browser. On receiving this the browser would ask the employee to select the probably unique certificate he has. Clearly the only thing that would make sense to use here would be the employee's company WebID. Here it is quite conceivable that the MITM proxy could have access to the user's private key, or even more simply that the proxy could create himself a public/private key pair and put the public key on the Employee's WebID Profile. The company would need to seriously trust the proxy software and maintainers of course.
Received on Saturday, 12 February 2011 19:11:18 UTC