[tptacek]

Thankfully, the world does not depend on Google to move decentralized trust for TLS forward; since it's mostly a UX change, and it's confined to a very small part of the TLS stack (the verification of server certificates), it can be retrofit over existing infrastructure with neither changes in server software nor major changes to browsers. We can probably do it via plugins.

[stanleydrew]

What can those of us who like this decentralized CA whitelist idea do to help it gain adoption? Can I start telling Chrome right now to use a whitelist maintained by an external source? Should I just pick someone's whitelist (e.g. ACLU, EFF, yours) and trim my browser and OS whitelists to only use those?

Also how does this affect SSL certificiate "pinning" as implemented in Chrome? I guess it doesn't since even if you have a pinned cert for a specific domain Chrome will still verify the trustworthiness of the CA that signed it?

[tptacek]

Sorry, I should also have mentioned TACK, Moxie and Trevor Perrin's proposed system of allowing servers to dynamically update certificate pins. As many people here know, Chrome already has a system of pinned keys, which mean that as far as Chrome is concerned, Chrome is the final arbiter of GMail's public key, not Trustwave or any other CA. TACK allows browsers to keep a cached list of pins in somewhat similar fashion to HSTS, which caches a list of servers that must use TLS.

TACK is just a proposed standard right now; I have no idea where it's going. But it's a good band-aid on the existing CA system.

[ivanr]

Several things come to mind; let's take Convergence (http://www.convergence.io) as an example. First, the software (Convergence plugin and notary code) need to be stable. This is mainly the job for the project team, but they might need help. In my personal experience, the code works well; haven't checked recently to see how it performs for others. The Convergence plugin is a hack, so it probably has a few rough edges.

Second, the protocol and the code need to be independently reviewed. This hasn't happened as of yet, but I am sure will if the popularity of Convergence increases. I'd be willing to give it a go at some point.

Third, we need a good-enough infrastructure to start with. SSL Labs (which I run at Qualys) sponsors Convergence by providing 4 notary servers (2 in the US, 2 in Europe). These notaries are installed by default, so you could say that the infrastructure is decent (at the current level of usage).

Finally, we need to have the technology available in all major browsers, at the very least pre-installed and available as an option, but -- ideally -- fully integrated ("This looks like a self-signed certificate; please wait for a moment while we verify that you are not under an attack"). A big problem for adoption is that browsers are lacking APIs for this type of work.

[StavrosK]

That's what the Perspectives plugin for Firefox (http://perspectives-project.org/) does, but, as with all these things, it probably won't see wide adoption until it's implemented in a browser by default (and it's good enough that it will have very few false positives or negatives).

[andrewcooke]

just to add that perspectives also has a chrome alpha - https://chrome.google.com/webstore/detail/lnppfgdnjafeikakad...

[kinda frustrating that the solution to many of these issues is sitting here at the bottom of the thread!]

[StavrosK]

Oh, thanks, I looked for that on the site but didn't spot it.

[adlwalrus]

I wonder what building a Chromium version would entail. Do you think it would be a lot of work? I feel like it would have been done already if it were possible with the present extension APIs.