Jim Starkey wrote: > When you get down to essentials, that's basically the same technology that I'm suggesting for a key server, the only difference is the certificate says a trust third party vouches for me as opposed to the key server already knowing the IPs. And, not incidentally, the key server idea doesn't require the pain and expense of buy and maintaining certificates.
Validating by IP is one way, but pinning down to specific clients has its own merit as well because of the NAT issue, and you don't need to buy anything to run your own certificate authority: this is a good use case for that. Rather than have client certs be bought from a third party (GoDaddy or Verisign or whatever), the operator of the db server would set up their own mini-CA and issue client keys signed by the server end. Then, when clients connect, rather than validate the cert by chaining down from the known root CAs, it just validates against its own internal CA (plus, you'd have to set up a CRL, something that's straightforward, though in practice I suspect many skip this step). None of this requires spending any money with a third party, nor *trusting* a third party, and the client who's handed the cert doesn't have to do any kind of verification on it. This may not scale to really large installations that have many many clients, but most of the bad stuff with PKI (Verisign and Godaddy, mainly :-) is eliminated. Steve ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
