Re: Summary of Camerfirma's Compliance Issues
On Friday, January 22, 2021 at 10:01:22 AM UTC-8, Ramiro Muñoz wrote: > El miércoles, 20 de enero de 2021 a las 5:04:27 UTC+1, Matt Palmer escribió: > > On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via > > dev-security-policy wrote: > > > Camerfirma is not the member with the highest number of > > > incidents nor the member with the most severe ones. > > No, but Camerfirma's got a pretty shocking history of poor incident > > response, over an extended period, with no substantive evidence of > > improvement. *That* makes me not want to trust Camerfirma, because I have > > no confidence that problems are being handled in a manner befitting a > > globally-trusted CA. Further, Camerfirma's continued insistence that "it's > > all better now", in the face of all the contrary evidence, does not inspire > > confidence that there will be future improvement. > > > > - Matt > Hi Matt. > > As we recognized previously, we have room for improvement. As we remain open > to suggestions, we are still working a lot on incident response, action > details and language skills. Why exactly should Mozilla trust your record of failure to improve on these after the first, second, third, fourth, fifth, sixth, seventh, eighth, etc. time? Far from getting better Camerfirma continues to have issues with implementing obvious steps to manage risks in the issuance process. It is not the job of members of this forum to tell CAs how to shape up, it's the job of CAs to not misissue certificates. It's actually more important than issuing certificates. Why should I believe that Camerfirma can do the job? We're on to double Latin letters for a CA that has a very small issuance volume over very few years. About once every 1.5 months on average Camerfirma has a deficiency. It's a shocking error rate, made even more shocking by the failure to learn lessons and its worsening over time. Many of the issues stem from a reliance on manual processing and inability or unwillingness to automate routine validity checks, even after the folly of this approach has been made clear. Another class of issues involve failure to properly manage delegation of authority, be it trusting WoSign, uncontrolled CAs not disclosed, etc. A third overarching theme is continued denial and making of excuses. This is not the right attitude a publicly trusted CA should have. Every one of these incidents was an unacceptable violation of trust, that by the terms of inclusion needed to be reported with a detailed answer as to actions taken in response. You've consistently failed to articulate in these incidents a root cause analysis, what steps will be taken to prevent a recurrence, and failed to learn from the failures of other CAs or even your own issues. In several cases commitments Camerfirma made to the community were not followed through on: see issue LL, where commitments from issues J and Z were seemingly undone, and the supposed remediation was incomplete. After issue R, issues T, PP, and RR should have been impossible. It is not your English that is lacking but your candor and sense of duty to the responsibilities with which you have been entrusted. I do not understand how any statements on your part can restore confidence given this record. I do not understand how Mozilla can trust any remediation plan Camerfirma articulates when the past response to incidents has been lackluster, incomplete, and, incredibly, continued to get worse. The proposed remediation actions strike me as woefully insufficient and should have been taken as part of any incident response already. I see no remedy but distrust. Sincerely, Watson Ladd > > Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
One issue that really stands out for me is "Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)". Despite detailed public discussion on the risk and remedial actions (including what would properly demonstrate destruction of the affected CA keys through e.g. ISAE3000 independent key destruction witnessing) CamerFirma failed to deliver any report providing proper assurance to the community that the affected CA keys have been properly and completely destroyed. If I understand the details disclosed in crt.sh correctly, it seems that in the case of CamerFirma one of the CAs having the OCSP signing EKU set (https://crt.sh/?id=12729554) appears to have been operated by a third party "CONSEJO GENERAL DE COLEGIOS OFICIALES DE MEDICOS". Not having assurance on the destruction of CA keys held within the CA's own environment is one terrible thing. In the case of the above CA certificate we are confronted with an even worse situation were a third party sub-CA potentially still holds keys (because no proper assurance on destruction) that can be abused to craft certificates and manipulate chain validity status of certificates in scope of the Mozilla root program. Camerfirma does not have any technical capability to prevent or stop this scenario would if ever materialize, as the certificate revocation by the parent CA / Camerfirma can be overwritten by keys of a CA that has the OCSP signing EKU set, and we simply don't know if they were destroyed properly. Can Camerfirma provide additional details on why they did not work with an external auditor to produce key destruction witnessing reports (which was so apparent they should from the public discussions and what other affected CA were doing) and confirm in which environment the above mentioned CA key (https://crt.sh/?id=12729554) did/does effectively reside? Matt Palmer: > On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via > dev-security-policy wrote: > > Camerfirma is not the member with the highest number of > > incidents nor the member with the most severe ones. > No, but Camerfirma's got a pretty shocking history of poor incident > response, over an extended period, with no substantive evidence of > improvement. *That* makes me not want to trust Camerfirma, because I have > no confidence that problems are being handled in a manner befitting a > globally-trusted CA. Further, Camerfirma's continued insistence that "it's > all better now", in the face of all the contrary evidence, does not inspire > confidence that there will be future improvement. > > - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
El miércoles, 20 de enero de 2021 a las 2:07:31 UTC+1, Paul Kehrer escribió: > On Tue, Jan 19, 2021 at 6:37 PM Jonathan Rudenberg via > dev-security-policy wrote: > > > > On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote: > > > 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. > > > > I strongly agree. The consistent pattern of documented failures and > > insufficient remediation is deeply problematic, and reflects a level of > > danger to Mozilla users that can only be mitigated by distrusting the CA. > > > > Jonathan > I also agree with this sentiment. Camerafirma's extensively documented > issues (https://wiki.mozilla.org/CA:Camerfirma_Issues) and the > responses in this thread reveal a CA which cannot responsibly handle > the burden of being a publicly trusted authority. > > -Paul Hello Paul, Jonathan I am sorry that you have this feeling. I would like to know what comments in this discussion reveal that we cannot take responsibility for the burden of running a CA. I would be happy to give you more detailed information to clarify your doubts. We see that in some answers we have not been understood or we have no be enough clear. KR Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
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 > 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
Re: Summary of Camerfirma's Compliance Issues
El viernes, 22 de enero de 2021 a las 2:31:00 UTC+1, Filippo Valsorda escribió: > 2021-01-19 18:01 GMT+01:00 Andrew Ayer via dev-security-policy > : > > 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 > In my personal capacity, I want to stress how worrying this response by > Camerafirma is. Arguing that a certificate doesn't present any risk if it's > issued for a name that doesn't exist in DNS betrays a deep misunderstanding > of the web platform, which the WebPKI serves. (For example, an attacker in a > privileged network position can fake a DNS response for that domain, and use > it to set Secure cookies on the whole site.) Hi Filippo, thanks for your contribution. I think there has been a misunderstanding about Camerfirma answer since we do not argue that issuing a certificate for a name that doesn't exist in DNS doesn't present any risk. We meant that in this specific incident there haven’t been any security issues because this specific certificate – and the corresponding private key – was used inside a closed and protected environment. In fact, it was managed internally by the SubCA itself because it was one the three technical certificates (a valid one, an expired one and a revoked one) that every CA shall create and install according to clause 2.2 of CAB Forum BR: it was never sent outside this environment and released into the wild, where – indeed – it could have created some risks. Nevertheless, the bug is still open, and we are giving additional information to evaluate it. https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
El miércoles, 20 de enero de 2021 a las 5:04:27 UTC+1, Matt Palmer escribió: > On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via > dev-security-policy wrote: > > Camerfirma is not the member with the highest number of > > incidents nor the member with the most severe ones. > No, but Camerfirma's got a pretty shocking history of poor incident > response, over an extended period, with no substantive evidence of > improvement. *That* makes me not want to trust Camerfirma, because I have > no confidence that problems are being handled in a manner befitting a > globally-trusted CA. Further, Camerfirma's continued insistence that "it's > all better now", in the face of all the contrary evidence, does not inspire > confidence that there will be future improvement. > > - Matt Hi Matt. As we recognized previously, we have room for improvement. As we remain open to suggestions, we are still working a lot on incident response, action details and language skills. Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CCADB Update: Extended ALV to EV SSL Audits on Intermediate Certs
CAs, There are a couple updates to the CCADB that I would like to bring to your attention. 1) Added 'CCADB Release Notes' link to the CA home page. It links to: https://docs.google.com/document/d/1yMLYQFNH2JnOixVsByC99uoQd8fFfZcKlKBu-vgy3CU/edit#heading=h.6p4mru6ujyvl 2) Extended automated Audit Letter Validation (ALV) to EV SSL audits for intermediate certificates. - Added ‘EV SSL Capable’ checkbox to the bottom of the ‘Certificate Data’ section on intermediate certificate records. [https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable] - Added CA home page Task list item called ‘Intermediate Certs with Failed ALV Results for EV SSL’. -- When it is non-zero, click on the ">" next to ‘Check failed Audit Letter Validation (ALV) results for EV SSL’, which is below the Summary section. Then click on the link in the 'Certificate Name' column. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
