On Monday, July 15, 2024 at 5:22:30 p.m. UTC-4 Tim Hollebeek wrote: The world would be better if we all knew, IN ADVANCE, which certificates are automatically replaceable, and which aren’t. This would also greatly streamline operations when replacements are necessary, as it removes the burden on making the determinations with a ticking clock, which is a situation that doesn’t lend itself to careful and unbiased evaluations.
The information could even be contained in a certificate extension, so that the rotation practices of these organizations is transparent. This sounds like a great idea, provided that browsers only trust certificates with the "never revoke" extension if the duration of the certificate is sufficiently short. I was thinking 2 weeks, but maybe the 20 days proposed by Ben? Definitely less than 30 days. If this idea is adopted, Mozilla (and other root store operators) can confidently add any misissued certificates without this extension to CRLite (or equivalent) 24 hours[1] after they are reported, regardless of whether the CA agrees to revoke by the deadline. One potential downside is that this would make critical certificates stick out like a sore thumb, but I think on balance, the transparency is more valuable than the disclosure risk. I’ve never been a huge security by obscurity fan, anyway. Agreed. The two hurdles I see are convincing the CABF to allow irrevocable certificates in the BR, and convincing customers who use certificates on critical infrastructure to use certificates with a shorter duration. I did a bit of digging, and imagine my surprise to find out that the CABF already[2] incorporated this idea into the BRs as "Short‐lived Subscriber Certificates". So make that only one hurdle. The good news is that CAs can start offering these "irrevocable" certificates to customers today; there is no need to wait for any further BR changes or root store policy updates. Peter Harris [1] Assuming Mozilla et al adopt Amir's proposal to disallow the 5-day option [2] https://cabforum.org/2023/07/14/ballot-sc-063-v4-make-ocsp-optional-require-crls-and-incentivize-automation/ -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d2478df7-00a0-4553-a8ab-733e3c3dc2ban%40mozilla.org.
