Ian,
Ian G wrote:
OCSP is unsuitable for many servers' use for performance reasons. The server usually can't afford to make an outgoing OCSP request and process an OCSP response for every incoming connections. This process roughly doubles the overhead of the server per incoming connection, and therefore more than doubles the cost of running it. You'll basically need twice as much server hardware if you use OCSP vs not using it. This is not even taking into account the cost of running the responder.
I'm guessing here you are referring to servers set up to accept client side certificates?
Yes, in part.
But server applications also sometimes make outgoing connections to other servers; ie. they act as clients. Eg. a secure web server may talk to an LDAPS directory server over SSL. Revocation checking is useful for those servers too.
Wouldn't such servers be generally set up under fairly close system administration control? And thus take themselves out of the scope of "default" policies such as envisaged by the default root list distros.
Indeed, the servers most likely wouldn't be using the default root list. The nssckbi root cert module would probably not be loaded. The servers would be using root and intermediate certs installed by the server administrators manually into the server's cert databases.
This doesn't change the fact that revocation is still wanted in those environments.
I don't know much in this area - I've not seen too much in way of servers that do client certs nor deal with CRLs, etc. Do Mozilla actually deliver a server?
AFAIK, mozilla.org does not deliver any server product.
However, the open-source NSS library which is used in free mozilla client products is also used under the MPL in commercial server products from Sun and RedHat, which are derived from the old Netscape/AOL server products. Nearly all of NSS development is paid for by those companies.
It would be a way of simplifying the debate; It seems as if there are two potential 'sets':
1. Firefox, etc, people who are 'average users' and expected not to touch defaults. For this application, OCSP may help. Phishing is a problem with this set.
2. Servers, etc, adminstrators could be expected to be 'savvy' and capable of dealing with CRLs and root lists. Hackers may be a problem here, and phishing may be a *secondary* issue, after the info has been extracted from users, but if client side certs are in use this would be a much more sophisticated breach involving virus/trojan compromise at the minimum.
Does that fly?
Yes, those are definitely different types of users. But the main differences lie in the way of application administration and user interface, not in the way the underlying crypto and PKI library works.
The commercial server products have staff to work on their admin security UIs. The mozilla client products don't. Until somebody steps up to work on it, most of the discussions in this newsgroup that relate to UIs will remain just wishful thinking.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
