The root of the problem lies in that, in the current conditions, the entity issuing the certificates cannot be expected to scrutinize the certificates it issues. One possible way to overcome this limitation is by having a second trusted third party (hereafter: a “Verifier”) attest for CAs and the certificates they issue. This can work as long as the Verifier has no financial interest in doing a bad job. The market can be used to discriminate between good and bad such Verifiers.

As an example, imagine that browsers are taught, by an add-on or a plug-in (all main browsers support some plug-in architecture), to consult a third party server, the server of the Verifier, before trusting any certificates they are about to use. The Verifier is one of the user’s choice; each user decides which Verifier plug-in he installs in his browser, and this plug-in connects to a given server. The Verifier server is consulted on-line in an OCSP-like protocol (we mostly discuss web browsing, so on-line connectivity can be assumed to exist.) The browser either uses the certificate or not, depending on the response from the Verifier.

The Verifier server that gets the query can either perform the lookup based on a white list, or more likely, based on a black-list. Black-list lookup makes more sense here. We do not want to make the user avoid any web server the Verifier doesn’t happen to already be familiar with. Of course, white-list is more secure, because any certificate not known will not be trusted, however, given this is a second line of defense (the first line being the existence of a certificate by a CA), the black-list approach may be preferred. According to this approach, the Verifier server checks that the certificate that the browser is about to use does not appear in a list of certificates that are known to have been erroneously issued. If the certificate does not appear on the list — the browser is notified that it is clear to use it.

The certificates examined by the Verifier need not consist only of the certificate of the specific web server to which the client browser wishes to connect. It may consist of all of the certificates along the chain linking the server certificate to the root certificate recognized by the browser. For example, the Verifier can store references not only to suspect web-site certificates, but also references to certificates of CAs that are known to issue such suspect certificates. This approach is preferred not only because it is easier to manage, but also because, by the black-list model, it prevents the owner of a malicious site from repeatedly obtaining new certificates from his cooperating CA, each time its current certificate is black-listed. Black-listing the CA, rather than the certificates it issues, thus makes more sense.

One may argue that there is no difference between this model, of a third party Verifier, and merely having the user remove from the browser CA root keys of CAs which he does not trust. There are two main differences between the two. First, from the manageability perspective, users cannot be expected to do this. Most users do not know how to mess up with the root CA list, and more importantly, they cannot be expected to remain in the watch for new CAs that they should no longer trust. It will just not work, as it hasn’t so far. Second, sometimes the cause of trouble is not the root CA (which the browser matches to an entry in its repository, which can be removed), but an intermediate CA somewhere in the middle. These do not have a cached key in the browser that can be removed, and one would not want to avoid using an entire root CA just because one of its sub-CAs happens to issue non-trustworthy certificates.

The motivation of the Verifier to carry out this business is to be addressed. It shall not get money from CAs, obviously, so to keep its independence. It probably should be a non-profit organization, or have indirect revenue channels like that of some security plug-ins, e.g., by displaying web pages with ads whenever the plug-in is updated. Hopefully, there is more than one such Verifier, with each user consulting one or more of them, based on market-maintained reputation.