You are, oddly, the first person I've actually seen who has a reason (along the boundaries of X.509) to allow any certificate the user wants to authenticate with, regardless of whether the CA is known.
It is entirely possible to do what you want, within TLS and X.509. (X.509, by the way, is an ITU standard which allows for "certifying authorities" to strongly bind a real-world identity to the public key in the certificate, signed by the certifying authority's public key.) You need the client to generate a keypair, send the public part off to the CA (whose CA? Why, yours, of course) after performing some other authentication magic, and then return the CA-signed certificate that includes only the essentials that you need: the username and the public key. Once you configure your main application to request certificates issued only by your CA and shunt them over to the registration process if they can't provide one, the main application only receives certificates that the user sends that are signed by your CA. Thus, you can be certain that the username that the CA placed in the certificate is valid and preregistered. That's perhaps a bit overengineered, but it'd be possible. -Kyle H On Sat, Jul 11, 2009 at 9:45 AM, <openssl-us...@coreland.ath.cx> wrote: > Hello. > > I'm considering writing a server program (which provides mostly > hypothetical services, for the purpose of this discussion). The server > requires users to register an account on the server before use. The > service would, I believe, simply bind usernames to one or more > user-provided public certificates. > > Also, for the purposes of this discussion, I control both server and > client code. > > I want to use TLS to handle authentication/encryption but am not sure if > it's feasible. Specifically - I don't want users to have passwords, it > must be public key authentication only (like SSH) with bilateral > authentication. This is a critical point - I would like the only realistic > way to compromise a user account to be actually stealing the private key > of that user and cracking the password on it (assuming a lack of other > software bugs and/or poor user interfaces allowing social engineering). > > I'm not 100% certain how to implement this securely, however. Would the > server cache a copy of each user's public certificate? I'm trying to work > out what guarantees TLS actually provides (on the strongest settings - > which both the client and server would enforce). > > Any input would be appreciated. I appreciate the question is a little > vague, hopefully I'll be able to expand on it after some responses. The > main reason I'm trying to get a better picture of this stuff is that I'm > no cryptographer and obviously any protocol I invented would no doubt be > subject to many cryptographic flaws... > > xw > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
