The goal of the proposal is to enable the use of strong authentication for all TLS connections over the internet. The certificates as things-in-themselves don't really matter, they are actually just a vehicle to post the public key of the user/server in a reliable public place. The security occurs when the challenges to prove private key ownership are cross-issued by each party. MITM would not have the private keys to answer either challenge.
Note that this still doesn't solve the problem of MITM obtaining the server's private key. I'm still working on that one. Karl From: Phillip Hallam-Baker [mailto:[email protected]] Sent: Wednesday, September 11, 2013 11:50 To: Theodore Ts'o Cc: Karl Malbrain; [email protected] Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o <[email protected]<mailto:[email protected]>> wrote: On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote: >Rather than have each TLS server receive user public certificates >individually for strong authentication, implement a global user public >certificate list hosted internationally that supplies user public >certificates to TLS hosts and clients. The list would be read-only, >indexed by GUID, and hosted at multiple international sites. Both TLS >servers and clients could then reliably obtain public certificates by >GUID for use in strong authentication challenges per the TLS protocol. And how would this global public certificate directory be securely updated? If you simply accept valid certificates, then it doesn't solve the rogue/comrpomised CA problem. The normal way this is done in practice is for every relying party to issue their own certificates. Which completely destroys the point of using public key. If the issuer is going to be the only relying party you might as well use symmetric crypto and a proof of knowledge which is what I have tried to do in the HTTP Session ID proposal. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
