|
|
|
|
|
by isostatic
2652 days ago
|
|
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." [0] https://news.ycombinator.com/item?id=19377292
[1] https://news.ycombinator.com/item?id=19375758 |
|
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.