I agree with you that we will probably always need some sort of commonly-trusted authorities. Most users don't have the resources to properly identify every entity that they interact with over the 'net, and even those who do might prefer to delegate some of these tasks. And good software authors need to be able to offer reasonable defaults, especially since they won't be able to assume the existence of anything like an external validation agent (which would itself need reasonable defaults) for a long time to come.

So given that we're going to need some centralized authorities, how should software and operating system authors choose and deploy their pre-trusted roots? It seems to me that all of these principles are needed:

• trust only root authorities with well-established verification practices.
• trust a wide enough range of roots that most secured systems on the 'net today will cleanly validate.
• do not trust any root with known bad practices, and be able to deprecate trust in a root relatively easily if it proves to be untrustworthy.

Ideally, these decisions would not need to be fully black-or-white either, to allow some root authorities a "probationary period" where they are not fully trusted, but can still contribute to the infrastructure.

Unfortunately, the current X.509 deployment sets these principles at odds with each other, and it has no mechanism for anything but black-or-white, fully-trusted or not-at-all root authorities.

In practice, what happens is that software authors simply cast as wide a net as possible to ensure that all valid sites are detected by default their software. What incentives do they have to limit their list of trusted roots? What mechanisms do they have available to them to put authorities on probation?

Certificate authorities themselves currently make money from issuing certifications -- they have little to no incentive to avoid issuing certs other than bad press. It's unclear what amount of bad press would be needed to actually unseat an entrenched trusted root in the current model.

If the user has an interest in preventing forgeries, site administrators are even more perversely aligned against it than software authors. Since X.509 allows only one certifier per certificate, every site administrator is effectively bound to advocate for their certifier's inclusion in the list of default trusted roots. Since the subject of the X.509 cert foots the bill for the certificate under today's X.509 model, the administrator also has the incentive to purchase the cheapest cert (which often translates into the most fly-by-night, lowest-overhead "authority"), and then to advocate for their inclusion in default trusted root lists.

In such a racket, there is no effective way for any smaller player to start participating, and there is no effective way to deprecate any entrenched authority without causing massive disruption to anyone certified by that authority.

Allowing certificates to have more than one issuer, and enabling software authors to grant marginal trust to probationary authorities would address both those problems. This is most easily conceived by using OpenPGP certificates for TLS. The Monkeysphere project can already demonstrate the use of OpenPGP certificates to authenticate SSH connections, though it does not include any trusted roots by default. Work remains to adapt similar principles to other transport layers.

-- Daniel Kahn Gillmor <dkg@fifthhorseman.net>