Adding trust assurance to SSL through web of trust

See the previous post for background if you're not familiar with why SSL can't solidly be trusted.

UPDATE: I created an additional post for existing solutions.

One method which has been proposed for SSL certification path trust is DNSSEC (SECure DNS).  If DNS is "trustworthy", then why not add an extension to DNSSEC to leverage the hierarchy for SSL certs?  RSnake has a good post on this method.

Personally, I don't like it.  DNS is still a distributed hierarchy, and can be subverted at the individual server level.  If my DNS server is compromised, then I can't trust the addresses it gives me, and so I can't trust the certs it tells me.  "Lawful Intercept" is also a problem here: governments can assert authority over companies, and can likely compromise DNSSEC in the same way they're apparently compromising SSL.

In my opinion, the better solution is the old "Web of Trust".  Suppose I publish a blog entry saying "mail.google.com is using a SSL cert from Thawte".  You read that post.  Then, if you visit mail.google.com and find that it's using a different cert, it's an indication that something weird is happening.  Conceptually, it's similar in this application to Crowdsourcing.

Here are the requirements I see:

Global diverse distribution	Publish SSL cert paths for large numbers of websites on a large number of different Trust servers, so my browser can randomly select a few for its check. Large numbers of Trust servers will make take-downs difficult to orchestrate, and global diversity will make legal countermeasures difficult to implement.
Client convenience	Build it into the browser so the action happens automatically on page load. Reduce the barriers to client adoption.  Browser plug-ins are a good start.
Server convenience	Make it very easy for random internet users to set up Trust servers, to increase the number of servers available, like WordPress plugin easy.
Self-Policing	Trust servers should monitor the data from each other, to detect changes and "outside interference".
Cross-linking	It must be easy to find Trust servers. The naive answer is for servers to recommend other servers - but then a compromised Trust server could direct the browser to other compromised Trust servers.
Dynamic	Trust servers should track client queries as updated data points. It will build the Trust tables quicker, and larger samples make anomaly detection easier.

Now come the hard problems to solve: the design conflicts.

• Anonymity vs. Data Integrity:  Anonymous usage is a strong design goal for a Trust server, but anonymity makes it easier to poison the data through malicious updates.
• Anonymity vs. Anomaly Detection:  Trending information will be incredibly useful to find out whether certain jurisdictions are applying SSL trust spoofing.
• Trust Coverage vs. Server Resources:  How to make each Trust server able to store large number of website cert paths, while not requiring multiple GB of data.  This is probably the easiest "hard" problem.
• Legitimate Updates vs. Illegitimate Actions:  If a website legitimately changes its SSL cert, how does that information propagate?

Other questions to consider:

• Should Trust leverage p2p techniques like Torrent?  Clients can cross-communicate, cache other client IP addresses...
• What kind of statistical history should be kept, and what kind of analysis performed?  Should anomalies be tracked?
• Can anti-spam techniques such as reputation be applied?
• Should there be different levels of trust between servers?
• Is it worth the effort to implement?
• What's a good name?  How about p2pki?

Comments welcome as always.