Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA
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,
Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA
> - Sending a link that must be accessed to approved is known-insecure, as > automated mail scanning software may automatically dereference links in > e-mail (in order to do content inspection). Confirm/Reject buttons alone > shouldn't be seen as sufficient to mitigate this, as that may vary based on > how the crawler works. Requiring explicit entry of the random value is a > necessary "human" measure (aka similar to a CAPTCHA) We do actually have a CAPTCHA above the [CONFIRM] / [REJECT] buttons, which must be filled before proceeding. Is this not considered sufficient? I wonder because I have recently seen this same email DCV method process in other CAs (link that must be accessed to approve), and no captcha nor explicit entry of the random value is required; just “approve” button (not even “reject”). If it was deemed necessary, instead of including the RV in the link, we could include the RV in the email, and require the applicant explicitly enter this RV in the webpage. > - You haven't described how the email address is constructed for these > cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and > if and only if the domain contact is the same for all of the requested > domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it > would be inappropriate if hostm...@apex1.example could approve a request > for apex2.example, yet, as currently described, that seems to be possible, > in that both hostm...@apex1.example and hostm...@apex2.example will > receive the same Request ID to approve/reject the request. For *each* of the domains to be included in the certificate, a email for DCV purpose has to be chosen from the ones the system automatically lists: 1) Constructed emails, using admin@, administrator@, webmaster@, hostmaster@, or postmaster@ + apex domain. (method 3.2.2.4.4) 2) Result of the WHOIS lookup previously made, for the “technical contact”, or “administrative contact” (method 3.2.2.4.2). The WHOIS lookup is performed automatically by making a query to the whois service corresponding to the tld. This method can only be used when there is public information available and the registrar/WHOIS provider has not masked it, otherwise, this option is not available. We do not reuse the Random Value. Each DCV email receives an independent email with a unique RV. Following your example, let the domains be apex1.example, apex2.example, and apex3.example. It would show 3 dropdown lists (one for each domain) with the emails to choose form: · apex1.example: acceptable emails as listed above. - e.g. Chosen email is hostmaster @apex1.example · apex2.example: acceptable emails as listed above. - e.g. Chosen email is admin @apex2.example · apex3.example: acceptable emails as listed above. - e.g. Chosen email is webmaster @apex3.example 3 emails would be sent: · To hostmaster @apex1.example - containing request ID (or "order ID"), unique RV and download link for program. · To admin @apex2.example - containing a link with a RV unique to this domain. · To webmaster @apex3.example - containing a link with a RV unique to this domain. In NO case apex1.example receives the same random value as apex2.example. So hostm…@apex1.example could not approve a request for apex2.example or apex3.example. Maybe the term “request ID” was what caused confusion. It refers to an identifier of the certificate request itself (maybe I should have called it “order ID”), not the RV. We are working on supporting other DCV methods in the near future (by April), specifically .13, .14. since are the most similar and easier to integrate in our current system. Also studying the option of integrating method .7. Regards, Pablo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA
> The reason we reject human error as a root cause, which you don't seem > to understand because you mention the engineers, is that failures are > NOT the fault of humans who make mistakes. They're the fault of the > system which failed to prevent the mistakes. > The mention of the engineers, coupled with the note in the incident > report about "Disciplinary Measures and Sanctions", suggests that ANF > intends to use the threat of punishment to try to prevent mistakes. I believe that you have overlooked many of the reinforcement measures that I indicated in my previous email for the sake of your final conclusion. Measures that show that in ANF AC, we work so that our systems avoid the errors that humans could make, and that these would prevent errors that other included CAs have made (I gave some examples). I pointed out several automated measures, however, the conclusion you reach is that we "intend to use the threat of punishment to try to prevent mistakes”... The existence of said document “Disciplinary Measures and Sanctions” is not “threat of punishment”, it is a normative and legal obligation, by ETSI EN 319 401, whose REQ-7.2-05 indicates “Appropriate disciplinary sanctions shall be applied to personnel violating TSP's policies or procedures”; which refers to clause 7.2.3 of ISO/IEC 27002:2013 for guidance: "There should be a formal and communicated disciplinary process in place to take action against employees who have committed an information security breach." Your interpretation that a “Disciplinary Measures and Sanctions” Policy is intended to intimidate our staff is far from reality. Contrary to that, this documented processes in an organization are intended to avoid arbitrariness and guarantee a unified criterion, which is known throughout the organization. _ Regarding Domain Control Validation, I apologize for trying to be brief in my previous answer. I will go into more detail, so that it can be understood how ANF AC proceeds to validate the requests: At the time of request, when indicating the domain or domains to be included in the certificate, the automated checks described in my previous email are performed (regarding correct format, posible errors, CAA Records, Google Safe Browsing list, ANF AC blocklist) to prevent an “invalid” request from proceeding. Because, it makes no sense to allow a request for an invalid domain to proceed, or for a domain with CAA RR containing unknown property tags with the Critical bit set, or with “issue” or “issuewild” that does not authorize issuance by ANF AC. Here, also a WHOIS lookup is made. It is important, for the explanation further below, to indicate that in the request we also require the applicant's phone number. Next, for each of the domains to be included, a drop-down email list is shown with the following options to choose from: 1) Constructed emails, using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain (which would be method 3.2.2.4.4) 2) Result of the WHOIS lookup previously made, for the “technical contact”, or “administrative contact” (which would be method 3.2.2.4.2). This is in case the content of said contact is in email format. If the content is protected by privacy it is not listed. In the case of single-domain, when formalizing the request, two codes are sent via: - Request confirmation email: Contains the request ID (numeric), a random alphanumeric code valid for 29 days, and a download link for “ANF Certificate Manager” program. - SMS: Random code (code 2). In “ANF Certificate Manager” the applicant must enter the request ID, the email code and the SMS code. The program then shows all the request information (applicant info, data of the subject, DNS to include in SAN…) and the applicant must give confirmation. Said request is then sent to ANF AC in order to validate the rest of the documentation (explained further below), and proceed, if favorable, to the issuance of the certificate. NOTE: "ANF Certificate Manager" is a client desktop program that incorporates a tool so that the applicant can generate their key pair on their Windows PC. This makes it easier for the client to later download the issued certificate, and export to pfx if needed. Here I want to clarify that in NO case ANF AC generates the keys and returns them to the program, it is the program tool that generates the keys on the applicant's PC. (as I saw it was discussed at https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001949.html). We also allow the option for the user to provide CSR that was generated by their preferred means. In case of multi-domain, it does not make sense to send N emails with instructions to download the program, since it only needs to be downloaded 1 time. Therefore, what the system does is: send the request confirmation email to one of the emails, and send an
