On Wed, Dec 26, 2018 at 06:02:57PM +0000, Jeremy Rowley via dev-security-policy wrote: > Much better to treat this question as “We know X is going to happen. > What’s the best way to mitigate the concerns of the community?” Exception > was the wrong word in my original post. I should have used “What would > you like us to do to mitigate when we miss the Jan 15ht deadline?” > instead. Apologies for the confusion there.
I think that *could* be a productive discussion to have, assuming that (a) it isn't a hypothetical (as in, "tell us what we'd have to do, and we'll decide if that's more pain than just following the rules in the first place") and (b) that there *is* something meaningful that can be done, *before* the deadline would otherwise expire. Insofar as DigiCert has been reasonably upfront about the issues they're facing, and willing to engage in discussion, that isn't a bad thing. Certainly, it's better than the alternative. Apart from that, though, I'm not coming up with anything that *has* to be done before the deadline, that would help to mitigate the problems associated with this incident. One thing that I think *would* be useful would be to know, in sufficient detail that the community can see that it *would* work, how DigiCert is planning to change their practices and processes such that a similar kind of incident cannot happen again in the future. Now that it is absolutely and blindingly obvious that certificates may need to be replaced at any time due to circumstances outside the CA's control, what does DigiCert intend to change in order to ensure that their subscribers will *always* be prepared to replace their certificates at short (ideally, five days, as per the recent BR changes) notice? If DigiCert had a plan to ensure that, and executed on it in a reasonable timeframe, it would go a long way to assuaging my worries, at least, that we're all going to be in this exact same position at some point in the not-too-distant future. - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
