Here is a marvelous and fun description, by Moxie Marlinspike, of what is wrong with today’s conventional wisdom on SSL certificate authorities. I like very much one of his slides: He cogently describes why DNSSEC does not support trust agility. He shows in one simple slide the logic of the proposal which I had not penetrated in an extended perusal of the documents—the cert of the target is returned with DNS response. The data may be distributed, but whom you must trust is not. Even with DNSSEC one may choose an alternate DNS root, until, that is, your ISP chooses to preclude that option in the name of security.

Marlinspike dismisses the option of distrusting a specific CA as making parts of the web go dark. This has not been my experience. Just because some rely on the authenticity of a specific site when they visit the site, does not mean that I need rely on the authenticity of that site. There is a small handful of sites whose authenticity I depend on and I have taught my browser to recognize their specific certs (not CAs). For other sites I have no expectations of particular behavior that would require assurance. It is true that Apple’s Safari has a bug when it promises to continue after encountering a distrusted site cert; instead it loops with the warning, other browsers proceed after the warning just fine.

The Convergence scheme has much to recommend it and is much better than the current CA situation or DNSSEC proposal, but I want a more fundamental change such as the httpsy protocol where the YURL becomes a secure designator of the target site by virtue of including the site’s cert’s fingerprint.

If you send me a YURL to a new site and tell me why I should trust it, and I trust you in such things, then I can safely use that YURL and no other parties are involved. It can be a self signed cert (or an unsigned cert for that matter). If another friend tells me of the same site with another recommendation and a YURL with the same ‘fingerprint’ than I gather trust in that site. I need tools to compare the parts of the two YURLs that identify the site, but that is simple and can be done by eye by the YURL savvy user. The browser or e-mail system can keep track for you of the chain of recommendations that led you to use some site. In this scheme there are no “security servers” outside the sites that I visit.

The convergence scheme addresses initial contact with an institution whose name you have heard of outside computer channels, or by reading insecure web content. I imagine a site that maintains a map from cert finger prints to roughly what PKI calls the common name. Such a site could tell you what it knows about particular certs or YURLs. There is no monopoly on such service and you can consult several, somewhat as the convergence proposal suggests.

This explores such issues and relates to other proposals.

The YURL takes its insight from capability discipline and indirectly from notions that Granovetter introduced with a Y shaped picture, thus the ‘Y’ in “YURL’. The secure identity of the intended recipient is maintained thru the chain of custody of the YURL. We do not depend on avoidance of collisions in Domain Name Space.

The Convergence scheme requires accurate transmission of the URL and stable DNS service. It is not clear that the recent DNS poisoning attack on the Register and other sites this week would not have fooled Convergence. The YURL would not have been fooled. (The YURL requires accurate transmission as well along with authentication of sender.)

The YURL affords a gradual introduction but the benefit comes along with the gradual introduction.

Google’s Chrome’s perspective on Convergence.
A scheme from CMU