On Wed, Nov 30, 2005 at 04:44:10PM +0100, Bernhard Froehlich wrote: > As I see it it's more or less a matter of taste wether you implement > such things using certificate extenstions or use the database approach. > Some things to consider: > > - You can't modify certificate extensions, you'll have to create a new > certificate if the user gets a new IP-Adress > - Using certificate extensions may be preferable if you have many > servers and many (changing) users since then you won't have to > distribute the database to the servers
We're going this route, because essentially we have many "servers" and not that many clients. We very definitely want to be issuing the clients new certificates if anything about them changes. Each server, however, is an embedded machine, a long way away with intermittent internet connectivity and often even being physically inaccessible (swapping a machine out often requires a cherry-picker and sometimes bio-hazard gear...) Hence we need to do the authentication from the client end, by using their certificates to pass through authority to use given machines; we can't sensibly change the ip or name list on all the servers when the clients move. The problem of the client having to come to us if they change IP is in fact /exactly/ what we want; since it prevents anyone picking up the client certificate/key pair and wandering off with them. Even if they can do that, they then need to fake the IP address to match the certificate, and since the real clients are online, there's going to be routing problems... it's another obstacle for an attack, essentially. And we're in the realm of trying to make attacks more expensive than the reward. > Lost or stolen certs should be handled by certificate revocation, at > least that's why certificate revocation and revocation checking was > implemented. > But as I said, there may be people with other opinions. Or situations > where immaculate theory is not the decisive factor. ;) Part of our problem is that we don't necessarily know that certificates have been stolen.. we're also using short expirations on them because again, updating a revocation list on the server machines is infeasible. We're expecting 10,000 server installations and 50 or so clients. It's clearly easier to make the server a fire-and-forget and do all interraction through the client; we're essentially in charge of who can talk to what, when and from which ip addresses. Hence the certificate nicely fits the job of a secure way for us to delegate authorities.. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
