An initial report of a possible timing side channel was made on 14th July 2020
by Hubert Kario (Red Hat). A refined report identifying a specific timing side
channel was made on 15th July 2022 by Hubert Kario.
The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario.
If so, it's interesting that it took exactly 2 years and 1 day for the refined report.
EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.
Maybe in this case! You can look at P1v15 RSA and assume that there might be some kind of behavior oracle, which is definitely not the same thing as demonstrating that there is a viable oracle. A problem with P1v15 in general is that you have to mitigate these kinds of covert channels directly.
But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.
Right, especially in this case where you can almost just go from TLS library to TLS library saying "hm, this implements P1v15, probably has a timing channel" to get credit for the eventual finding. :)
Right. In a lot of cases "this implements RSA" and "this wasn't written by Thomas Pornin" is enough to suspect a timing channel. Writing a proof of concept for one is at least an order of magnitude more challenging; at least in my experience. (I am way better at mitigation than exploit development.)
It took 2 years to find out that a potential vulnerability actually exists. There's a lot of potential vulnerabilities that may or may not actually be exploitable.
For a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months.
But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a maximum lifespan of 398 days.
People tend to think about it as a year or two years because the way a for-profit CA used these limits was to sell annual certificates but allow early renewal without losing out. Say you bought a cert on June 10th 2022, this year as the end of May approaches you get an email (In reality use automation, please) saying hey, you should renew soon. You can pay up on 29th of May, you get a new certificate which expires on... June 10th 2024. They couldn't do that if the rules didn't allow enough extra days.
The CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways.
No debate, no re-vote, no giving anyone any extra time or warning.
That's how it should work: the major browser vendors and their root programs should be calling the shots. Participation in CA/B is a favor they do the CA industry, nothing more. The rise of activist browser root programs correlates with essentially everything good that has happened in the WebPKI.
EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.