Hello Andrew, I am very aware that in the past the CA has made errors and misissuance, I fully understand the context and the seriousness of the matter. As CA we understand that it makes no sense to rely on "nothing serious ever happened", and the correct thing is to assume the importance of these errors, give explanations to the community and act to prevent them from happening again.
It is my purpose to gain the confidence of the community in ANF Autoridad de Certificación (ANF AC) and guarantee the operation of the CA in compliance, that is why I would like to take your intervention as an opportunity to give the pertinent explanations, comment on the substantial improvements applied in our PKI since then, and clarify those past bugs that remain confusing. I completely agree that "Human error" is not an acceptable analysis, and "training improvement" is not the optimal solution. We have worked to apply as many automatic controls as possible to reduce any possible human error to a minimum, and the team of engineers who made those mistakes at that time are no longer in our organization. ANF AC made a profound change, both in human and technical resources. We reviewed pretty much all the resources provided by Mozilla regarding frequent incidents and misissuances and the wiki pages dedicated to grouping incidents of specific CAs (which in many cases have led to their distrust), and finally we have established multiple automatic controls both in processing the request as in the moments prior to issuance. These controls, already applied and fully automatic, are as follows. Regarding the domain: • Automatic validation of the TLD is performed against IANNA’s Root Zone Database https://www.iana.org/domains/root/db to avoid Internal Names (BR 7.1.4.2.1) • The FQDN must comply the “preferred name syntax” in RFC1034 modified by RFC1123. • Domain and subdomain can only start with a letter or digit, end with a letter or digit. The only interior characters accepted are letters, digits and hyphen (so not underscore “_” - BR 7.1.4.2.1, or spaces “ “). • Duplicate entries are not allowed (as we saw it happened at: https://bugzilla.mozilla.org/show_bug.cgi?id=1357067) • Double automatic verification of CAA Records, at the time of formalization of the request and prior to the issuance. • Automatic check against Google Safe Browsing List (GSB) • Show warning and set aside for manual review in case of repeating 2 times a TLD registered by IANNA (com.com, net.net ...) (as we saw the case of suspicious com.com certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=1672409) • In the case of Wildcard, both verification of the correct position of the asterisk (*) and suitability for the requested profile. • If it contains more than 4 consonants in a row, which is unusual, shows a warning of potential typo is displayed. Regarding the data of the subject, among others: • To avoid typos of "geographic errors", we have standardized the values of stateOrProvinceName and localityName (locality whenever possible, given the magnitude) fields for Spain, and the countries of our main clients, using both official data and examples of certificates issued by other local CAs in those countries. This is also applied, in case of EV, to jurisdictionStateOrProvinceName and jurisdictionLocalityName fields. • In the case of countryName being Spain, our main market, we have established automatic controls regarding the VAT number format (NIF), and a direct and automatic query to the official Spanish records to obtain the organization name as it is officially registered. • In the case of countryName being Spain, automatic assignment of CategoryBusiness according to the VAT number format (to avoid incidents like this we saw here https://bugzilla.mozilla.org/show_bug.cgi?id=1600114). The first letter of VAT numbers in Spain indicates the legal type of the organization, so its easy to automate this classification. Regarding domain validation, we are able to use the BR methods (3.2.2.4.2), (3.2.2.4.4) or (3.2.2.4.15). Measures have been applied to ensure that domain validation is not skipped: • In the request process, emails built using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain are automatically listed. The random request confirmation code will be automatically sent to this email. • In case of being multidomain, one of them is chosen to send the confirmation code and the rest, each one will be manually validated in the validation process (which also includes verification of documentation and other data) by our IRM staff (Issuance Reports Managers) • Before confirming the issuance order, the IRM staff must indicate, for EACH domain, which domain validation method (of those indicated in ANF AC CP) was used, with current BR version number and attach files that provide evidence for this. Othewise it cannot proceed with issuance. In addition to this, we have automatic pre-issuance lint using cablint, x509lint and zlint. To reinforce the improvement of our controls, I subscribed to Bugzilla's CA Certificate Compliance and CA Certificate Root Program components to closely monitor bugs about mississuances and incidents other CAs included have and apply controls to avoid them. Responding to the misunderstanding with the “Test certificates” that you pointed out, ANF AC CPS (since the update of December 5, 2019) indicates: “ANF AC does not issue SSL/TLS test certificates out of publicly trusted roots”. In that Bugzilla bug I clarified that, eventhough we were going to apply the measure as a poison extension, we investigated to find examples of this, and found one in a request for inclusion by Microsoft (which by then was as recently as some months ago) in which the OID was put in the certificate policies extesion. This reasoning was accepted by Mozilla as per https://wiki.mozilla.org/CA/Application_Verification, (and I quote Wayne Thayer in another thread) "a lack of comments indicates that the community is satisfied with the review that was performed on the inclusion request". As Ryan then told me, “if anything is confusing, out of expectation, or seems more permissive, it is important to raise these as concerns”, we should have raised this as concern before assuming it was OK and change our position, as it was definitely not OK. However, we also made clear no test certificates would be issued by Publicly Trusted Roots. With the measures listed above, fully applied now, I can assure that what happened with the certificate issued for "cdcdcd" would not have been possible. In the request process it would have already been rejected. The automatic controls on the domain would have pointed out multiple errors, among others it does not comply with the “preferred name syntax”. The request for said certificate would not have proceeded in the first place. This measures also prevent those compliance problems to reoccur under the new hierarchy ANF Secure Server Root. I believe that this should be taken into account to understand how ANF AC currently operates a publicly trusted certificate authority. We do not have lax control measures. I hope that the above shows the ability of ANF AC to learn and improve from the mistakes that were made, and to meet and try to exceed the minimum expectations. I remain at your disposal to clarify any other aspect or give more clarifications to what is indicated in this email. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
