[einhverfr]

On the other hand we found that as of Friday, Chrome DID NOT recognize that one of our wildcard certs for Efficito had been revoked. We sent out an email to our customers saying to enable cert revocation checking.

Revovation isn't perfect and I would not suggest the current status quo is OK but the intermediary approach Chrome takes cannot be trusted as they have now shown.

If Chome will not show our cert as revoked what is the point of revoking the cert? The author has points but the approach Google ie taking is a cure worse than the disease...

[chmars]

Honestly, I don't see a point in certificate revocations anymore, i.e., your implicit conclusion seems to be correct. And I don't blame Google for our broken revocation system – especially because the even the best revocation system couldn't fix the current certification system that is broken in its core.

[einhverfr]

Google's problem is they decide which revocations are worth passing on to the browser. That's at least as broken by design.....

Believe me I am aware of the limits of soft-fail, but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

[enneff]

Soft fail doesn't work at all. CRLset works for the certificates that it covers (some 25k of them, btw).

Which approach is worse?

[mpyne]

> but the answer cannot be even in the short-run to let a browser vendor tell us which revocations are worth knowing about.

So you trust the browser vendor to ship you executable native code but you don't trust the browser vendor to apply reasonably decent criteria for the top x% most-needed cert revocations on the Internet?

[tptacek]

Do you know the limits of "soft-fail"? Because I don't see you addressing them.

[richardwhiuk]

Revoking certificates is pointless - that's Adam's point here.

[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.