[cryptography] Client certificate crypto with a twist

Jon Callas jon at callas.org
Wed Oct 10 10:29:31 EDT 2012

Hash: SHA1

On Oct 10, 2012, at 6:52 AM, Jonathan Katz wrote:

> Looking at this just from the point of view of client-server authentication, how is this any better than having the website generate a cryptographically strong "password" at sign-up time, and then having the client store it in the password cache of their browser?
> Note that both solutions suffer from the same drawback: it becomes more difficult for a user to log on from different computers.

An excellent point, Jonathan.

I also wonder why there has to be any certification at all?

Right now, web sites store a user name and a representation of a password. (Note that a password, a hash of a password, etc. are all representations of that password.)

Why not store a representation of a *key* (a hash is a representation of a key) and then prove possession of the key? It doesn't need to be certified. I can store that key on as many computers as needed via a keychain or something like it.

Of course, one could have that key be part of a certificate for the times that that is necessary. In the general case, it doesn't need to be certified though. If all I'm doing is creating an account on your server, you don't need to certify my key. You might want to certify my account in some way (like an email round trip, etc.) but why propagate that to the key?

Certification is a very nice hammer. It drives a lot of nails. I don't think it's needed here.

I'll also add that SSH authentication by key does what I'm describing. You attach a key to the account and then prove possession of the key. There are of course, many ways to do this that don't use the SSH mechanism, but SSH follows the general sketch.


Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii


More information about the cryptography mailing list