El martes, 19 de enero de 2021 a las 18:01:49 UTC+1, Andrew Ayer escribió: > On Sun, 17 Jan 2021 00:51:29 -0800 (PST) > Ramiro Mu__oz via dev-security-policy > <dev-secur...@lists.mozilla.org> wrote: > > > Some certificates may have been syntactically > > incorrect due to misinterpretation, but we have never compromised any > > vetting, identification or information validation. > This is false, as shown by incidents like > https://bugzilla.mozilla.org/show_bug.cgi?id=1672423 > (issuing for a non-existent domain) and > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 (not checking CAA), > not to mention the validation failures by sub-CAs for which Camerfirma > is ultimately responsible. And even misissuances that are just > "syntactically incorrect" are concerning because they show a disregard > for the policies that exist to prevent harm to innocent parties. > > It's troubling that even at this stage, Camerfirma still doesn't seem > to grasp the seriousness of their compliance problems. Today, > they are arguing that there was no security threat from a certificate > issued for a domain without authorization because the subdomain > in the certificate "does not exist": > https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8 > > Camerfirma was warned in 2018 that trust in their CA was in jeopardy, > yet compliance problems continued. There is no reason to believe > Camerfirma will improve, and there are many indications that they won't. > Mozilla's users deserve CAs that take security more seriously than this. > It's time to take action to protect Mozilla's users by distrusting > Camerfirma. > > Regards, > Andrew
Andrew Thanks for your contributions. For the sake of clarity, I would like to split your comments: A. For what concerns 2018 and 2019 issues (https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 and https://bugzilla.mozilla.org/show_bug.cgi?id=1672423), we did not consider those certificates as a security risk because they were never delivered. Furthermore, those errors have been already fixed and nowadays detected automatically. B. For what concerns 2020 issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8), there is a more complex explanation in this bug about potential security threats: reducing it to the statement “the subdomain in the certificate does not exist" is in some way misleading. In fact, the certificate should have been installed by the SubCA itself for hosting the expired web page (this certificate is part of the three “technical” certificates as required in clause 2.2 of CAB Forum BR) but – due to a mistake – it was not installed. This is the reason why the SubCA is confident that the certificate was not used, and it did not produce any security issue. When we say that security issues are more important than compliance ones, we do not (at all) disregard compliance issues: we just start from the technical side to comply with both. We are trying to analyse our bugs and security issues, making more improvements both on regulatory and technical side: this approach has led us to reinforce also our compliance procedures. All those failures you mentioned were fixed, and – in addition – we deployed automatic controls to avoid them in a future. After the said 2018 warning to comply with the request of improvement, we have done many actions: • Control cablint, x509lint and zlint (pre-issuance - post-issuance) (January 2019). • Additional automatic control to verify the correction of AKI extension before certificate issuance (April 2020). Automatic verification of CAA (June 2020). • Control of the DNS and Email domain (August 2020). • Syntax control of the domain (August 2020). • Control of black and whitelists of domains (August 2020). Regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
