On Fri, Jul 3, 2020 at 8:06 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Ryan, > I don’t think I’m failing to see the security problem, but we evidently > have different perception of the risk level for the particular case of > internal delegation. > Anyway I will just cease in my intent and just act as it’s expected, > looking as guidance to the reaction of other CAs where possible. Again, I don’t disagree that it’s reasonable to see a difference between 1P and 3P if you’re a CA. But I look at the risk of “what attacks are now enabled if this is unaddressed”? Put differently, if a CA used a long-lived delegated responder, and I found out about it, I would absolutely be concerned and expect explanations. However, if the “worst” thing the delegated responder could do, if compromised, was “simply” sign OCSP responses, that’s at least better than the situation we’re in here. Because these delegated responders can, in many cases, cause new issuance, and because they are actively signing things other than OCSP responses (e.g. certificates), the threat model becomes unreasonably complex. The BRs have clear guidance on who absorbs the risk for a CA’s mistake: the CA and anyone who has obtained certificates from the CA. Historically, browsers have rather nobly stepped in and absorbed that risk for the ecosystem, introducing ever more complex solutions to try to allow site operators to continue with business as usual with minimal disruption. But that’s not what the “social contract” of a CA says should happen, and it’s not what the CP/CPS of the CA says will happen. It’s true that 4.9.1.2 “only” demands revocation, but any CA not treating this as recognizing the security impact and the similarity to a key misuse and/or compromise - even if “hypothetically” - does a disservice to all. I would just have a last request for you. I would appreciate if you can > express your views on Ben’s message about Mozilla’s position, in particular > about the 7-day deadline. > I think it’s of extreme benefit for all if the different browsers are > aligned. I participate here largely in an individual capacity, except as specified. I’ve already shared my risk analysis with Ben on that thread, but I also think it would be grossly negligent for a CA to try to look for “browser alignment” as a justification for ignoring the BRs, especially when so many platforms and libraries are put at risk by the CA’s misissuance. It sounds like you’re looking for an explicit “exception”, and while Ben’s message seems like a divergence from past Mozilla positions, I think it at least maintains consistency that “this is an incident, no exceptions”. Again, while wanting to ensure a safe space for questions, as a CA, your responsibility is to understand these issues and act accordingly. I wholly appreciate wanting to have an open and transparent discussion about the facts, and I am quite sensitive to the fact that there very well can be information being overlooked. As I said, and will say again: this is for your incident response to demonstrate, and as with any CA, and for any incident, you will be judged on how well and how timely you respond to the risks. Similarly, if you fail to revoke on time, how comprehensively you mitigate the lack of timeliness so that you can comprehensively demonstrate it will never happen again. Every time we encounter some non-compliance with an intermediate, CAs push back on their 4.9.1.2 obligations, saying it would be too disruptive. Heck, we’re still in a place where CAs are arguing even revoking the Subscriber cert under 4.9.1.1 is too disruptive, despite the CA claiming they would do so. This **has** to change, and so it needs to be clear that the first order is to expect a CA to **do what they said they would**, and revoke on the timetable defined. If there truly is an exceptional situation that prevents this, and the CA has a second incident for complying with the BRs for not revoking, then the only way that can or should not result in distrust of the CA is if their incident report can show that they understand the issue sufficiently and can commit to never delaying revocation again by showing comprehensively the step they are taking. There is little evidence that the majority of CAs are capable of this, but it’s literally been a Baseline Requirement since the start. For lack of a better analogy: it’s a borrower who is constantly asking for more and more credit to keep things going, and so they don’t default. If they default, you are unlikely to get your money back, but if you continue to loan them more and more, you’re just increasing your own risk for if/when they do default. The CA is the borrower, defaulting is being distrusted, browsers are the lenders, and the credit being extended is how flexible they are when misissuance events occur. Taking a delay on revocation for this issue is asking for a *huge* loan. For some CAs, that’s beyond the credit they have available, and the answer is no. For others, it might be yes. Just like credit scores are used in credit, different CAs have different risks based on how well they’ve handled past issues and, in some part, based on how well they handle this issue. The best way you can avoid taking on new “trust” debt, and even potentially pay down some of any existing debt caused by past incidents, is to promptly revoke and provide a key destruction ceremony report to that effect. Short of that, it’s going to depend on the incident report as to what happens and whether further credit is extended. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
