[Cryptography] On the deployment of client-side certs

[Jerry Leichter]

> About identity information leakage, the first SRP message sent from the client to the server includes plaintext identity, isn't it?
It's not clear to me how *any* mechanism in which a server has multiple clients can possibly work without the client first identifying itself so that the server can figure out who's logging in to it.  (Of course, I suppose any mechanism could be used with an expensive protocol in which the client *doesn't* identify itself but rather the server simply tries the credentials against every account it knows about.)

That said ... there's no reason why the client's unencrypted identity should be the same for different servers.  In fact, if your concern is that actions across multiple servers can be correlated back to the same user, it *shouldn't* be - at the least, even if everything else is protected, multiple conspiring servers could correlate their own users.

So, sure, you could use client certs - but you'll want to use a different one for each server, which is moving far away from the intended use case, where the cert identifies the individual user.

Note that if you assume everything is handled by software, both username and password should be "just bit strings", separate for each correspondent site.  (They could easily be generated in a deterministic way from the site identification and a single local secret.)

> About password being stored on an hardware token, then the SRP password secret turns into a long term discrete logarithm private authentication key. With this understanding, SRP enrollment with a server becomes equivalent to registering a unique public key for each server.
> 
> I do not know which exact scheme is easier and more efficient. Nonetheless, SRP with user-remembered password spares "secure mechanism to hold a private key" but requires a "secure mechanism to apply a private key." If you afford a secure hardware token, the SRP main benefit appears less relevant.
SRP brings two things to the table:  It allows authentication without leaking any of the private information (the "password"); and it blocks brute-force attacks against weak passwords.  I would actually agree that the latter is overkill when the "password" is handled by hardware and can be assumed to be safe against such attacks.  So SRP is overkill.  But it's perhaps a bit less overkill than the whole cert structure, which has layers of stuff in it that are completely unrelated to the problem at hand.

If the goal is to leverage the existing infrastructure, perhaps "abusing" clients certs is the way to go.  But in fact client cert support seems to be in bad shape anyway, so there may not be enough existing infrastructure to make it worthwhile.

                                                        -- Jerry