I understand your skepticism, but I am not advocating a complex CA infrastructure and I have more faith in end users (possibly misplaced). IMHO, it is reasonable for users to take that extra step for their banking site or SSL-VPN. It's really not that big a deal to generate a key pair in PuTTY, I can't imagine it would be that hard in Firefox. The question about whether it will be immediately and enthusiastically adopted by end users on their Facebook site is not the point.
A bank or Paypal does not need to issue certificates. In fact, I believe that self-signed keys like in the PGP model would be more appropriate, because that key pair could be used for multiple sites. A single key pair could be used in different browsers and computers, and if they are lost, a new key pair could be generated and the old pair revoked by the user just like in PGP. With self-signed keys, you don't need to deal with CAs, CRLs, etc., which I agree would be too burdensome. Generating a key pair for SSH is pretty trivial, and using a wizard in Firefox would simplify it enough to be accessible to just about anyone. Yes, authentication boils down to trust. This is the advantage of using multi-factor authentication. You would then have something you know (username and password) and something you have (private key). This is required in the newer PCI & HIPAA requirements as well. On Sat, Nov 20, 2010 at 1:57 PM, Daniel Ruggeri <drugg...@primary.net> wrote: > > For those who have a real security need to authenticate their clients in > this way, and are willing to accept the hassles of this method, it is > definitely used. However, the idea that a bank or paypal would issue > certificates for each of its end users can get cumbersome very fast. See, > the private key would be managed by the user. Users (and even some server > administrators) are terribly poor at managing their private keys in a safe > and secure fashion. Some potential complications are a user switching > browsers, a user switching computers, a user's key becoming compromised, > loss of the key, etc... On top of that, the signing institution would need > to be able to keep track of certificates it should no longer accept via > CRL's and have infrastructure ready to verify the cert is still valid. > > Essentially, the logistics of getting END USERS to generate a key of > appropriate size (and getting them to keep it safe), send a CSR, sign and > return a certificate to them as well as the unavoidable technical support > involved makes this an unattractive option to large institutions because the > average Internet denizen isn't expected to know how to do this stuff The > Right Way. > > P.S. > IMHO, this conversation applies to PKI, X509 client authentication and even > password authentication... all of these mechanisms boil down to the fact > that there is some entity that knows who the user is and that your server > will have to take a leap of faith at some point to trust that the user > sitting at the keyboard is who they say they are. > > -- > Daniel Ruggeri > >
