On Wed, 10 Mar 2021 13:43:55 -0700 Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> This is to announce the beginning of the public discussion phase of > the Mozilla root CA inclusion process for the ANF Secure Server Root > CA. I'd like to draw attention to the first misissuance mentioned in <https://bugzilla.mozilla.org/attachment.cgi?id=9098945> and <https://bug555156.bmoattachments.org/attachment.cgi?id=9100493>. Although this misissuance occurred under ANF's old hierarchy, that hierarchy is/was trusted by Apple and Microsoft, and ANF was requesting its inclusion in Mozilla, so the incident is relevant to understanding how ANF operates a publicly-trusted certificate authority. In 2019, ANF issued a server certificate <https://crt.sh/?sha256=6C1F1CDA9E6BD20E300C84D3C54BABE5A79A7901E373C21DE0D63055F4935B52> with a DNS name of cdcdcd. Obviously, they could not have possibly validated domain control of this hostname, which is a serious failure considering that domain validation is the most important task a CA performs. However, their incident report doesn't mention domain validation at all. They blamed the incident on human error by "junior engineers" and their resolution was to implement a blocklist of words that indicate a test certificate ("Test", "Testing", "Prueba"), provide more training for junior engineers, and update their "Disciplinary Measures and Sanctions document, in order to have this resources available in case of infringement". None of these resolutions address the root failure to perform domain validation. Had this incident report been written several years earlier, it may have been excusable, but by 2019 it was very clear to anyone following mdsp and CA incidents that "human error" is not acceptable analysis and training is not an adequate resolution. Additionally, their incident report shows some pretty concerning misunderstandings of PKI and the BRs: 1. A belief that the CABF's Test Certificate extension OID is meant for testing their CA rather than a (now forbidden) domain validation method. 2. A belief that the CABF's Test Certificate extension OID is to be put in the certificate policy extension rather than used as the ID for a poison extension. 3. A conflation of the subject serial number and the certificate serial number, stating that the subject serial number must contain 64 bits of entropy. Finally, note that the new hierarchy has issued zero end-entity certificates known to CT, so the fact that the new hierarchy hasn't misissued any certificates doesn't speak to the competence of ANF. On the other hand, the history of misissuance in the old hierarchy, ANF's misunderstandings of PKI, and the incredibly poor incident report speak very poorly to ANF's competence and trustworthiness. There is no indication that they've corrected the root cause of their failure to perform domain validation, and no reason to believe that their compliance problems won't reoccur under their new hierarchy. When Mozilla trusts a CA, Mozilla is giving an assurance to its users that they won't be harmed by the CA. A CA which has lax technical controls, a poor understanding of PKI, and an inability to learn from and improve when mistakes are made is at heightened risk of exploitation by malicious actors that would harm Mozilla users. I do not believe Mozilla can give assurance to their users that ANF is safe. Therefore, this application should be rejected. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
