For a CA to intentionally state that they are going to violate the BR requirements means that that CA is under immense pressure to comply with demands or face retribution. The severity inflicted on a CA by intentionally violating the BR requirements can be severe. Rolling a dice of chance. Why take the risk?
On Thu, Dec 27, 2018 at 8:21 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'm not trying to throw you under the bus here, but I think it's helpful if > you could highlight what new information you see being required, versus > that which is already required. > > I think, yes, you're right that it's not well received if you go violate > the BRs and then, after the fact, say "Hey, yeah, we violated, but here's > why", and finding out that the reasons are met with a lot of skepticism and > the math being shaky, and you can see that from past incident reports it > doesn't go over well. > > But it's also not well received if it's before, and the statement is "Our > customer thinks we should violate the BRs. What would happen if we did, and > what information do you need from us?". That gets into the moral hazard > that Matt spoke to, and is a huge burden on the community where the > expectation is that the CA says "Sorry, we can't do that". > > So the assumption here is that, in all of this discussion, DigiCert's done > everything it can to understand the issue, the timelines, remediation, etc, > and has plans to address both each and every customer and the systemic > issues that have emerged. If that's not the case, then how are we not in > one of those two scenarios above? And if it is the case, isn't that > information readily available by now? > > From the discussions on the incident reports, I feel like that's been the > heart of the questions; which is trying to understand what the root cause > is and what the remediation plan is. The statement "We'll miss the first > deadline, but we'll hit the second", but without any details about how or > why, or the steps being taken to ensure no deadlines are missed in the > future, doesn't really inspire confidence, and is exactly the same kind of > feedback that would be given post-incident. > > On Thu, Dec 27, 2018 at 1:50 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > There's a little bit of a "damned if you do, damned if you don't problem > > here". Wait until you have all the information? That's a paddlin'. File > > before you have enough information? That's a paddlin'. I'd appreciate > > better guidance on what Mozilla expects from these incident reports > > timing-wise. > > > > -----Original Message----- > > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org > > > > On Behalf Of Jeremy Rowley via dev-security-policy > > Sent: Thursday, December 27, 2018 11:47 AM > > To: r...@sleevi.com > > Cc: dev-security-policy@lists.mozilla.org > > Subject: RE: Underscore characters > > > > The original incident report contained all of the details of the initial > > filing. The additional, separated reports are trickling in as I get > enough > > info to post something in reply to the updated questions. As the > questions > > asked have changed from the original 7 in the Mozilla incident report, > > getting the info back takes time. Especially during the holiday season. > > We’re also working to close out as many without an exception as possible. > > Note that the deadline has not passed yet so all of these incident > reports > > are theoretical (and not actually incidents) until Jan 15th. I gave the > > community the total potential number of certificates impacted and the > total > > number of customers so we can have a community discussion on the overall > > risk and get public comments into the process before the deadline passes. > > I’m unaware of any policy at Mozilla or Google that provides guidance on > > how to file expected issues before they happen. If there is, I’d gladly > > follow that. > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
