On Wed, Jul 24, 2024 at 04:52:51PM -0400, Mike Shaver wrote: > On Wed, Jul 24, 2024 at 2:36 PM 'Ben Wilson' via > [email protected] <[email protected]> wrote: > > Personally, I currently favor extending the timeframe for the revocation > > of certificates that have no security impact, > > I propose, tongue only slightly in cheek, that if a component of the > certificate doesn't have security impact, it be removed from the > certificate specification in the BRs.
I'm not sure why you'd have your tongue anywhere near your cheek -- it's an excellent proposal. The same question, of course, should apply to the BRs as a whole, rather than just certificate contents, as there are operational-related reasons for revocation, not just "the bits in the cert are wrong". > Are there any specific examples of what deviations of certificates would > be deemed so minor that they can stay live on the web for 20 days, but > still worthy of revocation? My reading of Ben's suggestion was that anything that CAs can currently take five days for would instead have a 20 day deadline, so it'd be any of points 6-16 in BR s4.9.1.1. While I can see the logic that leads to a suggestion of "let's give CAs and subscribers more leeway on the little things", I don't think it would be a win for the WebPKI. Revocation is already a "never" event (as in, many subscribers don't think it could ever happen to them); allowing CAs to reassure customers that not only won't it happen to them, if it *were* to happen to them, they'd have 20 days to remedy it, does not give any motivation to improve their certificate installation practices. Which means that when, say, an employee uses the private key of the company's TLS certificate as an example in a blog post[1], it'll still take the company a couple of weeks to get around to replacing the certificate. Which is not what we want to encourage. - Matt [1] This is not a hypothetical: https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key-redaction-redux.html -- 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/46696760-8a2e-493e-a931-87b40351aaa1%40mtasv.net.
