On Thu, Jul 16, 2020 at 12:45 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > We should reposition the debate again, because a false reality is being > assumed. > > Some people are assuming that this is the real situation: "A security > incident has occurred due to the negligence of certain CAs, and this > security incident has got worse by the CAs' refusal to apply the correct > measures to resolve the incident, putting the entire community at risk". > > But this description of the situation is not true at all, for many > reasons and on many levels. > > By order: > > a) There is no security incident. Since no key has been compromised and > there is no suspicion that a key compromise has occurred. > b) There has been no negligence, errors, or suspicious or malicious > behavior by any CA in the issuance of these certificates. All affected > certificates have been issued following good practices and trying to > comply with all the applicable security standards and regulations. > > c) The only relevant event that occurred recently (July 1) is that a > person, acting unilaterally and by surprise, reported 14 incidents in > the Mozilla Root Program about 157 ICA certificates misissued > (certificates issued with the EKU "OCSPSigning" without the extension > "OCSP-nocheck"). The wording of the incidents assumes that "his > interpretation of the standards is the correct one" and that "his > proposed solution is the only valid one". > > d) This is not a new incident since most of the certificates affected > were issued years ago. The existence of this ambiguity in the standards > was made public 1 year ago, on September 4, 2019, but the debate was > closed without conclusion 6 days later > ( > https://groups.google.com/g/mozilla.dev.security.policy/c/XQd3rNF4yOo/m/bXYjt1mZAwAJ > ). > > e) The reason why these 157 ICA certificates were issued with EKU > "OCSPSigning" was because at least 14 CAs understood that it was a > requirement of the standard. They interpreted that they must include > this EKU to simultaneously implement three requirements: "CA Technical > Restriction", "OCSP Delegate Responders" and "EKU Chaining". > Unfortunately, on this point the standard is ambiguous and poorly written. > > f) Last year, a precedent was created with the management of the > "Insufficient Serial Number Entropy" incident. Many CAs were forced to > do a massive certificate revocation order to comply with the standards > "literally", even if these standards are poorly written or do not > reflect the real intention of the editors. > > g) None of the 157 ICA certificates affected were generated with the > intention of being used as "Delegated OCSP Responders". None of the 157 > certificates has been used at any time to sign OCSP responses. > Additionally, most of them do not include the KU Digital Signature, so > according to the standard, the OCSP responses that could be generated > would not be valid. > > h) As a consequence of these discussions, a Security Bug has been > detected that affects multiple implementations of PKI clients (a CVE > code should be assigned). The security bug occurs when a client PKI > application accept digitally signed OCSP responses for a certificate > that does not have the "DigitalSignature" KeyUsage active, as required > by the standard. > > i) There is no procedure in any standard within Mozilla Policy that > specifies anything about "key destruction" or "reuse of uncompromised > keys". > > j) As long as the CAs maintain sole control of the affected keys, there > is no security problem. For a real security incident to exist, it should > happen simultaneously: (i) the keys were compromised, (ii) they were > used to generate malicious OCSP responses, (iii) some client application > accepted these OCSP responses as valid and (iv) the revocation process > of the affected certificate was ineffective because the attacker was > able to generate fraudulent OCSP responses about its own status. Still, > in that case there is a quick and easy solution: remove the affected CA > Root from the list of trusted CAs. > > k) The real risk of this situation is assumed by the affected CAs and > not by the end users, since in the worst case, the ICA key compromise > would imply the revocation of the CA Root. > > Hi Oscar, Unfortunately, there's a number of factual errors here that I think greatly call into question the ability for Firmaprofessional to work with users and relying parties to understand the risks and to take them seriously. I would greatly appreciate if Firmaprofesional share their official response on https://bugzilla.mozilla.org/show_bug.cgi?id=1649943 within the next 24 hours, so that we can avoid any further delays in taking the appropriate steps to ensure users are protected and any risks are appropriately mitigated. If this message is meant to be your official response, please feel free to paste it there. Unfortunately, I don't think discussing the point-by-point takedown of your confusion here is useful, because I think we've moved beyond discussing into the abstract and discussing very specifically about the degree to which Firmaprofesional is interested (or not) in collaborating to keep users safe. I think, barring an update within the next 24 hours, it seems reasonable to take this post as the final and official response, and begin taking steps appropriately to reduce risk. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
