[gojomo]

Still seeing lots of explanation about why the current system sucks, and not much about how a more robust system might be created and promptly adopted. Langley (the author) mentions short-lived certificates (either rapid expiration or via a 'must staple')... how soon can we enforce that? How short can that make the danger-period where the CA, and Google, and the "connected web" all know that a certificate is invalid, but a user-at-risk does not?

Why not other ways to rapid-broadcast invalidity in censorship-proof ways, so that a browser encircled by an enemy can quickly figure out something's wrong? (Or, why can't security professionals get around interdiction as effectively as copyright pirates do?)

[moe]

how a more robust system might be created and promptly adopted

I'm quite fond of how the SSH host key system works.

Prompt me the first time I see a new key, provide me with supporting evidence (e.g. show me how many people have previously accepted this fingerprint for this domain) and alert me the same way in the future if the key ever changes.

If the 'supporting evidence' was plugin-based then this system could quickly become more user-friendly and trustworthy than the current centralised system can ever be.

There could be plugins to automatically trigger a SMS challenge on first contact with particularly sensitive sites. Multiple competing P2P web-of-trust plugins, plugins that let you follow trust-lists from third parties, etc.

In the current system you rely on a single, very questionable opinion on the trustworthiness of a given certificate. In the new system you'd be presented with a trust-score compiled from a whole range of opinions. The sources of which you chose before-hand.

Of course this approach doesn't include a license to print money for corrupt CA organisations and is not going to happen for that reason alone.

[einhverfr]

Supporting evidence, to be worthwhile, must come from a trusted source, right?

[moe]

As said it should be pluggable. Yes you will still need seed fingerprints for a few independent plugins (like the CA list of today), and you still need to trust or vet the browser itself (also like today).

The point is that once this seed trust has been established, which ideally would need to happen only once in your lifetime (given proper sync/backup facilities), you gain actual control over who you want to delegate your trust to, if at all. On a site-per-site basis.

If an american, a chinese and an EU database independently agree on a fingerprint for a site then that would be an actual trust indicator. Very much unlike the perpetually compromised zoo of certificate authorities of today.

And obviously once there's a market for plugins you'd quickly see plugins going far beyond what we get to know today (read: essentially nothing). There could be subscription-based plugins providing detailed information about the remote party, down to credit ratings, company history, you name it.

[gojomo]

All interesting ideas... but don't directly address rapid trust revocation, as in the case of recent relevance: a site's private keys are assumed to have been compromised (as if by the heartbleed bug).

Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? Without additional innovation, that seems just as prone to the performance bottlenecks or soft-failure (on stale data or blocked connections) as the current system.

[moe]

Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection?

For Hacker News? No.

For my bank? Yes, absolutely.

The implementation of a fast and scalable lookup is not exactly rocket science (cf. DNSBLs). It's a political problem, not a technology problem.

[gojomo]

Definitely agree that prompt revocation shouldn't be as hard as these apologetics-for-Chrome imply, and this hasn't festered as an unsolved problem for so long.

[dvanduzer]

See my other post. Systems with shorter term authentication have been around for decades. The problem with X.509 is that it centralizes authorization with the browser vendor.