[einhverfr]

Well, if they were pointless Google wouldn't even hand you a subset of revoked certificates. The fact that they hand you a subset of revoked certificates from participating CA's makes their solution worse than the disease, frankly.

It might be ok if used in addition to checking revocation lists. However why should a bank get to have their certificate in the crlset but a saas provider not? Or do you really trust Google there?

Frankly Adam doesn't really believe revocation is pointless. If he did, he wouldn't even suggest that sending a valuable subset of certificates to the browser in a batch is any sort of solution at all. All that does, though, is create a two-class secure internet: those entities Google deems worth distributing revocation information for and those not. That isn't a solution to anything.

[tptacek]

Online revocation is pointless. It sounds like you didn't actually read the article, but are happy to slam the one team on the Internet that has given serious consideration to the obviously-broken SSL revocation system. Can I ask you to take a breath and reread the article?

[einhverfr]

> Online revocation is pointless.

So is getting a subset of revoked certs Google deems "valuable." In fact, that may be even more dangerous since it establishes first class secure sites vs everyone else.

Why should Yahoo's cert revocatins get in the CRLsets but not less well known sites? How is that less broken than online revocation?

Keep in mind, my big objection is:

Google did not distribute our certificate vocation in their CRLSet, presumably because we weren't large enough. That is not a fix for anything.

[tptacek]

This comment isn't responsive to mine.

[einhverfr]

Ok, fair enough. I am just making sure my objection to Google's approach is clear.

I would be OK if they guaranteed complete CRLsets from all participating CA's. Since they don't, their solution is more broken than what they are replacing.

So I acknowledge that online revocation is problematic. I just think the crlset approach is an order of magnitude worse when the crlset is a subset of revoked entries sent by the ca.

[tptacek]

Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.

[gojomo]

The implied-preference-set shouldn't be restricted to the false binary choice of "the broken standardized system" and "Google's half-fixed proprietary approach".

With the talent & resources that Google has, or the talent & resources that Mozilla has, or the talent & resources that Microsoft has, this should have been better solved, in a way that works for all TLS-reliant applications, years ago.

Using Chrome's built-in auto-updates to make a subset of "high-value revocations" work, at a daily frequency, for Chrome users only, is not a very web-friendly solution.

It's like a gated community hiring its own rent-a-cops... maybe that's an improvement for the fortunate ones on the inside, and maybe a necessary stopgap. But to people outside that perimeter – like someone whose revocation doesn't make it into the Google CRLSet – it feels like an abdication of duty by the web's stewards.

[einhverfr]

If Amazon, Yahoo, and the small SaaS provider are in the same boat security-wise, then you have the incentive to get the root problems fixed. Google's approach takes away that incentive from the large providers.

I don't think it is just a question of pretending. It is a question of making sure that everyone is in the same boat security-wise so that the root problems in fact get addressed.

What Google does is make Amazon more secure and the small SaaS provider less so. And it makes sure that the big providers have less incentive to fix the underlying concerns.

[nomailing]

hard revocation is not at all broken! The article is bullshit.