On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Threatening distrust over a discussion about applicability of requirements > seems contrary to Mozilla's open discussion policy, and I don't think that > should be an answer while there are still open questions about the language > in 4.9.9. That isn't what was said at all, and it doesn't do anyone any good to misrepresent it so egregiously. A CA using the arguments Corey made as part of their CA incident response? Absolutely. Because it's a terrible incident response, and a CA arguing that as part of an incident response is a CA that is arguing in bad faith, because it's the same argument over "intent" that has been shut down over and over. Separating out the security risk from the applicability of the BRs is > useful because it highlights potentially poor language in the BRs. For > example: > > Section 4.9.9: > OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST > either: > 1. Be signed by the CA that issued the Certificates whose revocation > status is being checked, or > 2. Be signed by an OCSP Responder whose Certificate is signed by the CA > that issued the Certificate whose revocation status is being checked. > In the latter case, the OCSP signing Certificate MUST contain an extension > of type id-pkix-ocsp-nocheck, as defined by RFC6960 > The requirement for no-check only applies in the latter case, which is if > the OCSP response is signed by an OCSP responder. How would the no-check > requirement apply if no OCSP responses are being signed by the responder. > If the ICAs aren't signing, why does it apply? > > Should the OCSP issue be fixed? Definitely. The security issues are > apparent. Good, that's the focus, and for some CAs, based on discussions had before filing this incident report, they did not see it as apparent, even after Robin's educational highlighting of the security issues nearly a year ago. > Should the BR language be modified for clarity? I think that conversation > is still ongoing and shutting that down with threats of distrust is counter > productive. > And I'm not shutting down that discussion. My examination of this incident in the first place was triggered by CAs, among others including GlobalSign and HARICA, not realizing that this was an existing requirement when I made an explicit proposal to clarify this in the BRs, by prohibiting `id-kp-OCSPSigning` from being combined with other EKUs. Would that have fixed 4.9.9? No, and so I'm making sure to also add that to the "Cleanups and Clarifications" ballot. And I'm sure the CABF Validation WG will no doubt, in light of this, realize that we need an "OCSP Responder" profile to go with the other profiles being worked on. The threat of distrust isn't over discussing how to make this *better*. That's of course welcome to highlight where requirements aren't clear. It would be entirely appropriate a CA would, as part of their incident response, argue this is *not an incident*. I would hate if CAs, particularly those in the CA Security Council, were to try and coordinate and argue it's not an issue. I would especially hate if CAs were to point to Corey's arguments in particular, as a means of trying to create a parallel construction for why they did what they originally did (which is, more likely, explained by just not reading/being aware of the requirements), especially if trying to avoid the need to come up with a plan to revoke these CAs. Corey's not making this argument as part of an incident response, and so I *do* appreciate his attempt to highlight issues to improve. However, I'm trying to make it clear that the argument for why this is not an issue is not valid, and if a CA were to try to argue WontFix/Invalid (or, more aptly, "won't revoke, we don't think it's relevant"), that'd be an absolutely awful response. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
