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,
