On Thu, Jul 2, 2020 at 7:13 PM Ben Wilson <bwil...@mozilla.com> wrote:
> We are concerned that revoking these impacted intermediate certificates > within 7 days could cause more damage to the ecosystem than is warranted > for this particular problem. Therefore, Mozilla does not plan to hold CAs > to the BR requirement to revoke these certificates within 7 days. However, > an additional Incident Report for delayed revocation will still be > required, as per our documented process[2]. We want to work with CAs to > identify a path forward, which includes determining a reasonable timeline > and approach to replacing the certificates that incorrectly have the > id-kp-OCSPSigning EKU (and performing key destruction for them). > I'm not sure I understand this. The measurement is "damage to the ecosystem", but the justification is "Firefox is protected, even though many others are not" (e.g. OpenSSL-derived systems, AFAICT), because AFAICT, Firefox does a non-standard (but quite reasonable) thing. I can totally appreciate the answer "The risk to Mozilla is low", but this response seems... different? It also seems to place CAs that adhere to 4.9.1.2, because they designed their systems robustly, at greater disadvantage from those that did not, and seems like it only encourages the problem to get worse over time, not better. Regardless, I do hope that any delay for revocation is not treated as a "mitigate the EKU incident", but rather more specifically, "what is your plan to ensure every Sub-CA able to be revoked as required by 4.9.1.2", which almost invariably means automating certificate issuance and regularly rotating intermediates. If we continue to allow CAs to place Mozilla, or broadly, browsers, as somehow responsible for the consequences of the CA's design decisions, things will only get worse. Setting aside the security risk factors, which understandably for Mozilla are seen as low, at its core, this is a design issue for any CA that can't or doesn't meet the obligations they warranted Mozilla, and the broader community, that they would meet. Getting to a path where this design issue, this lack of agility, is remediated is essential, not just in the "oh no, what if the key is compromised" risk, but within the broader "how do we have an agile ecosystem?" Weak entropy with serial numbers "should" have been the wake-up call on investing in this. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
