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
