2020-07-11 13:17 GMT-04:00 Oscar Conesa via dev-security-policy <dev-security-policy@lists.mozilla.org>: > 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.
In this section, you argue that we (the relying party ecosystem, I am speaking in my personal capacity) should not worry about the existence of unrevokable ICAs with long expiration dates, because we can trust CAs to operate them safely. > g) On the other hand, if the affected certificate (with EKU OCSPSigning) > does not have the KU Digital Signature, then that certificate cannot > generate valid OCSP responses according to the standard. This situation > has two consequences: (i) the CA cannot generate OCSP responses by > mistake using this certificate, since its own software prevents it, and > (ii) in the event that an attacker compromises the keys and uses > modified software to generate malicious OCSP responses, it will be also > necessary that the client software had a bug that validated these > malicious and malformed OCSP responses. In this case, the hypothetical > scenarios involving security risks are even more limited. In this section, you argue that we can't trust CAs to apply the id-kp-OCSPSigning EKU correctly and it's then our responsibility to check the rest of the profile for consistency. These two arguments seem at odds to me. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
