It isn't a problem in itself. It doesn't make the certificate any less secure in practice, even if we still used md5 as a hash.
The problem however as pointed out down-page [0] [1]
> If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly? Or internally, if you can't make sure you obey this silly rule, how are you making sure you obey these important rules?
> The reason for the urgent fixes is to promote uniformly applied rules. There are certain predefined rules that CAs need to follow, regardless of whether the individual rules help security or not. The rules say the certs that are badly formed need to be reissued in 5 days.
> If these rules are not followed and no penalties are applied, then later on when other CAs make more serious mistakes they'll point to this and say "Apple and Google got to disobey the rules, so we should as well, otherwise it's favoritism to Apple and Google."
That's a slippery slope argument, and the answer to slippery slope arguments is "We'll address serious issues with appropriate seriousness."
This specific error isn't a serious issue, as indicated by how little impact it's had on real-world security.
It's not favoritism to Apple and Google if they emit certs with 63 bits and get minor criticism and someone else, say, stops using random numbers to seed cert generation and gets raked over the coals. The latter case would require more urgent and serious attention.
It's not a slippery slope argument, it's an applying the rules argument. The rules don't allow for a difference between more and less serious infractions, they just need to be followed to the letter.
"If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly?" is a slippery slope argument. The response is "We allocate testing resources proportionally to the seriousness of the consequences of failure to adhere to a requirement, as any good engineering project does."
It's probably worth noting that the problem lasted three years and wasn't discovered by an exploit in the wild, but by followup spot-checking of Google certs as a result of spot-checking Dark Matter certs. I don't think seriousness of the issue is in dispute.
It's saying, you have an extremely important job for the functioning of the Internet, that everybody has to blindly trust you do right.
The moment we see a small sign that you don't do it right in some detail, then that trust is gone.
Consider all the details in the spec to be Van Halen's brown M&Ms (although that had no functional effect, and losing a bit of security does). They knew that if people did that right, then they could trust that they also read the details of the rest. If Google gets this wrong, we can't trust on that.
That's not a slippery slope argument. That'd say, if we allow this then you would then do worse things because we let it go. But that's not the argument.
The problem however as pointed out down-page [0] [1]
> If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly? Or internally, if you can't make sure you obey this silly rule, how are you making sure you obey these important rules?
> The reason for the urgent fixes is to promote uniformly applied rules. There are certain predefined rules that CAs need to follow, regardless of whether the individual rules help security or not. The rules say the certs that are badly formed need to be reissued in 5 days. > If these rules are not followed and no penalties are applied, then later on when other CAs make more serious mistakes they'll point to this and say "Apple and Google got to disobey the rules, so we should as well, otherwise it's favoritism to Apple and Google."
[0] https://news.ycombinator.com/item?id=19377292 [1] https://news.ycombinator.com/item?id=19375758