[londons_explore]

On one hand, this incident was a massive amount of work by probably thousands of people to replace all the revoked certificates. Certificates which are perfectly good for communication and do not pose any significant security risk.

On the other hand, allowing a CA to violate the BR's without pain will just encourage others to do so.

[y0ghur7_xxx]

> Certificates which are perfectly good for communication and do not pose any significant security risk.

Is it so? I remember that in 2008 someone was able to create a rouge CA certificate because of the predictability of serial numbers[1]. It was a different time: we still used md5, but are you sure the limited entropy used to generate serial numbers does not pose any security risk?

[1]https://www.win.tue.nl/hashclash/rogue-ca/

[tialaramex]

The difference here is one bit. The BRs say you must use at least 64-bits of entropy, EJBCA out of the box used 63-bits. A bad guy might need to spend say $40 trillion to make a bogus cert instead of $80 trillion. No bad guys have $40 trillion so it's irrelevant. And that would be if we were still using SHA-1 (which is broken, and so the entropy is all that would keep you safe against collision attacks) but in fact Actalis and other CAs are only issuing with SHA-256 which isn't broken.

This is a Brown M&M ‡. It doesn't actually matter in terms of security, 63-bits, 65-bits, it's never going to make a real difference. But we wrote 64-bits in those rules, if we can't trust you to obey that rule, who says you got the really important parts right?

‡ https://www.snopes.com/fact-check/brown-out/

[wereHamster]

It's not that Actalis has not tried to obey, or purposefully withheld information or tried to mislead the community. The disagreement is on how strict the interpretation of the BR should be.

Would Van Halen abort a concert if there was a single brown M&M in a bowl of 1000? Probably not because even though it's a violation of their contract, they got their point across, it still means the organisers had read through the full contract and tried to obey.

Reading through the discussion, I wish I could be as strict as Ryan Sleevi is in demanding that browsers fix their incompatibilities with the web's BR (ehm.. standards). Chrome, there's this bug where this element is placed one pixel off from where it should be (it's by no means critical and does not impact users of any website in any meaningful way, but according to the CSS Box Model Module Level 3 spec, paragraph suchandsuch it's wrong). How about you fix it by next week or I'll uninstall you from all systems on the world.

[schoen]

Further to tialaramex's great answer:

In the 2008 attack, the CA was using sequential serial numbers. They weren't randomized at all.

The attackers had to do a large amount of computation to produce colliding certificates even when they knew exactly what the rest of the content of the certificate would be.

In the aftermath of that, we got MD5 deprecation and also a requirement that certificates include randomness that wouldn't be predictable to the subscriber, so that the subscriber doesn't know what the collision target is.

It's a little complicated to foresee the exact size of the benefit from this in different threat models, but in the model where the attacker has the capability to produce two related texts with the same SHA-256 hash, the current precaution means that the attacker has only a 1/2⁶⁴ probability that using that capability in conjunction with a certificate issuance will yield a matching certificate.

In 2008, certificate issuance usually cost money for the subscriber, where now it needn't, but there are still issuance rate limits and there's now Certificate Transparency, so all of the attempts will become public.

A bigger risk is presumably an n-way collision capability where an attacker can produce, not just 2, but n related plaintexts that all have the same SHA-256. In that case the attacker has an (n-1)/2⁶⁴ probability per certificate issuance that the issued certificate has the desired hash, assuming nothing unexpected or uncontrollable happens during the certificate issuance. (Another tricky problem, for example, is the time of issuance, which can be specified accurate to the second by the CA and appears in the certificate.)

Especially when nobody has demonstrated a SHA-256 collision or research that's close to producing one, and all attempts would be public in Certificate Transparency, and all CA issuance is rate-limited in some way, it doesn't seem like even 1/2⁶³ is that bad. Just five or ten bits of entropy in the certificate would probably have been enough to stop the 2008 researchers' attack from succeeding at all.

The attack would also have to have been carried out while the existing certificates were being issued (if there was no successful attack during certificate issuance, there won't be an attack after-the-fact).

I like tialaramex's brown M&M analogy: browser vendors are concerned with ensuring that CAs take rules and policies very seriously, even if there's no conceivable way that a particular problem could be related to an attack or vulnerability.