Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
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
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
2020-07-11 13:17 GMT-04:00 Oscar Conesa via dev-security-policy : > 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
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
As a summary of the situation, we consider that: a) Affected certificates do not comply with the norm (EKU OCSPSigning without OCSP-no-check extension). They are misissued and they must be revoked b) This non-compliance issue has potential security risks in case of key compromise and/or malicious use of the keys, as indicated by Ryan Sleevi. c) No key has been compromised nor has the malicious or incorrect use of the key been detected, so at the moment there are no security incidents d) There are two groups of affected CAs: (i) CAs that maintain sole control of the affected keys and (ii) CAs that have delegated the control of these keys to other entities. e) In the case of CAs who DO NOT have sole control of the affected keys: in addition to revoking the affected certificates, they should request the delegated entities to proceed with the destruction of the keys in a safe and audited manner. This does not guarantee 100% that all copies of the keys will indeed be destroyed, as audits and procedures have their limitations. But it does guarantee that the CA has done everything in their power to avoid the compromise of these keys. 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. 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
