James A. Donald writes:
Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password.
They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE.
Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate.
HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time.
HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users.