On Sat, Jul 11, 2020 at 1:18 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> f) For CAs that DO have sole control of the keys: There is no reason to > doubt the CA's ability to continue to maintain the security of these > keys, so the CA could reuse the keys by reissuing the certificate with > the same keys. If there are doubts about the ability of a CA to protect > its own critical keys, that CA cannot be considered "trusted" in any way. > While Filippo has pointed out the logical inconsistency of f and g, I do want to establish here the problem with f, as written. For CAs that DO have sole control of the keys: There is no reason to *trust* the CA's ability to continue to maintain the security of the keys. I want to be clear here: CAs are not trusted by default. The existence of a CA, within a Root Program, is not a blanket admission of trust in the CA. We can see this through elements such as annual audits, and we can also see this in the fact that, for the most part, CAs have largely not been removed on the basis of individual incident reports. CAs seem to assume that they're trusted until they prove otherwise, when rather, the opposite is true: we constantly view CAs through the lens of distrusting them, and it is only by the CA's action and evidence that we hold off on removing trust in them. Do they follow all of the requirements? Do they disclose sufficient detail in how they operate? Do they maintain annual audits with independent evaluation? Do they handle incident reports thoughtfully and thoroughly, or do they dismiss or minimize them? As it comes to this specific issue: there is zero reason to trust that a CA's key, intended for issuing intermediates, is sufficiently protected from being able to issue OCSP responses. As you point out in g), that's not a thing some CAs have expected to need to do, so why would or should they? The CA needs to provide sufficient demonstration of evidence that this has not, can not, and will not happen. And even then, it's merely externalizing risk: the community has to constantly be evaluating that evidence in deciding whether to continue. That's why any failure to revoke, or any revocation by rotating EKUs but without rolling keys, is fundamentally insufficient. The question is not "Do these keys need to be destroyed", but rather, "when do these keys need to be destroyed" - and CAs need to come up with meaningful plans to get there. I would consider it unacceptable if that process lasted a year, and highly questionable if it lasted 9 months, because these all rely on clients, globally, accepting the risk that a control will fail. If a CA is going beyond the 7 days require by the BRs - which, to be clear, it would seem the majority are - they absolutely need to come up with a plan to remove this eventual risk, and detail their logic for the timeline about when, how, and why they've chosen when they chose. As I said, there's no reason to trust the CA here: there are plenty of ways the assumed controls are insufficient. The CA needs to demonstrate why. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
