> > Yes. But that doesn't mean we blindly trust the CA in doing so. And that's > the "security risk".
But the point then is that a delegated responder that had the required "noCheck" extension wouldn't be affected by this issue and CAs wouldn't need to react, and therefore the issue to solve is the "mis-issuance" itself due to the lack of the extension, not the fact that the CA certificate could be used to do delegated responses for the same operator of the Root, which is acceptable, as you said. In fact the side effect is that delegated responders operated externally that have the required no check extension don't seem to be affected by the issue and would be deemed acceptable, without requiring further action to CAs, while the evident risk problem is still there. > > I can understand that our views may differ: you may see 3P as "great risk" > and 1p as "acceptable risk". However, from the view of a browser or a > relying party, "1p" and "3p" are the same: they're both CAs. So the risk is > the same, and the risk is unacceptable for both cases. But this is not actually like that, because what is required now to CAs is to react appropriately to this incident, and you are imposing a unique approach while the situations are fundamentally different. It's not the same the derivations of this issue for CAs that had 3P delegation (or a mix of 1P and 3P), and the ones, like us, that don't have such delegation. In our particular case, where we have three affected CAs, owned and operated by WISeKey, we are proposing this action plan, for which we request feedback: 1.- Monday, new CAs will be created with new keys, that will be used to substitute the existing ones 2.- Monday, the existing CAs would be reissued with the same keys, removing the OCSP Signing EKU and with A REDUCED VALIDITY OF THREE MONTHS 3.- The existing CAs will be disabled for any new issuance, and will only be kept operative for signing CRLs and to attend revocation requests 4.- Within the 7 days period, the previous certificate of the CAs will be revoked, updating CCADB and OneCRL 5.- Once the re-issued certificates expire, we will destroy the keys and write the appropriate report In my humble opinion, this plan is: - Solving the BR compliance issue by revoking the offending certificate within the required period - Reducing even more the potential risk of hypothetical misuse of the keys by establishing a short life-time I hope this plan is acceptable. Best, Pedro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
