> 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 "additional" confirmation email to each email indicated for DVC purpose for each additional domain to include. Said "additional" confirmation email, addressed to the domain administrator, informs them that [Applicant Data] has requested an SSL certificate for their domain [Domain] by [Request ID] request, and instructs them to access a link (valid for 29 days, the email indicates the expiration date) where they can manually confirm or reject the request by clicking Confirm/Reject buttons. Evidence is collected as to whether the administrator of said domain confirmed or rejected, and it is received on the IRM platform. The IRM staff can see whether or not domain control was verified for each of the requested domains (they appear listed). If a DCV was rejected or was not verified, the request cannot proceed. Depending on the email that was used for DCV (chosen during the request), the BR method used is automatically recorded. The BR version used is set from the system, but is saved for each request. In that same screen, IRM staff can see and manually verify the data and documentation of the organization and the applicant, and must attach evidence of identity verification. As, for example, in section 3.2.2.1. of the BRs several methods are allowed to verify the identity of the applicant; The IRM must select from a drop-down the method it has used (from those established in ANF AC CP) and attach evidence of it. I cannot find a possible way of automation for this, it must involve personnel trained in legal aspects, and it is unfortunately subject to potential human error. Regards, Pablo _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
