Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Hi Ryan, Obviously it is just my personal opinion of the facts made in a public discussion forum. Like many other participants in this forum, I only give my professional point of view as a PKI expert. This does not mean that my opinion and my arguments are shared by the company where I work. I am not the person in charge of officially answering these issues at Firmaprofesional (as can be seen on the Bugzilla incident website) and I do not have the authorization from my company to do so. I reiterate that these are only opinions and arguments made in a personal capacity. I apologize if I have involuntarily hinted that this was the official position of Firmaprofesional. Maybe I should have used a personal email to participate in the forum. I also wanted to take the opportunity to apologize if I have offended you with any of my comments. It was not my intention at all. I believe that both Google and Mozilla are doing a great job in defense of PKI technology and digital certificates, putting the safety of users before the economic interests of CAs. Thanks to this great work, the willingness of CAs to fulfill their obligations has improved dramatically in recent years. We all remember what the situation was 10 or 15 years ago, when bad practices and misissued certificates were the usual practice without any consequences. What we have achieved is a great achievement for the community, and we must defend it. Although with some unilateral decisions, there is a risk that this open and objective security model of CA control will become a closed and totally arbitrary process, managed by a few multinational companies. I hope that within 24 hours Frmaprofesional will respond officially to the open ticket. I also hope and trust that in any case, Firmaprofesional will be treated fairly and equitably with respect to the rest of the other affected CAs. On 16/7/20 19:33, Ryan Sleevi wrote: 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
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
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
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
