On Fri, 12 Mar 2021 04:57:56 -0800 (PST) Pablo D__az via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> [...] > > 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. The fact that this team of engineers is no longer in your organization doesn't address the concerns; if anything, it raises more concerns. 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. Meanwhile, ANF is still relying on error-prone manual domain validation, as we shall see below. > [...] > > 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. What is the process for verifying that the applicant knows the correct Random Value? > * 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) This alone should be grounds for rejecting the application, and shows that your above claim that ANF has applied "as many automatic controls as possible" is false. We've repeatedly seen how error-prone manual domain validation processes are. CAs, especially those who have a history of failure, should not be issuing certificates using manual domain validation. > * 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 an automated system, it's unnecessary for staff to manually indicate this, as the system knows which domain validation method was used. What is the process for ensuring that staff do not report the incorrect validation method, or report that domain validation was completed when it really wasn't? > In addition to this, we have automatic pre-issuance lint using > cablint, x509lint and zlint. While this is good practice for ensuring that RFC 5280-violating certificates are not issued, it does not prevent certificates from being issued without proper domain validation, so it's not responsive to the core concern of ANF's failure to perform domain validation. Although this response does highlight some good practices that ANF has adopted, like preissuance linting and subscribing to the CA-related components in Bugzilla, it ultimately reinforces the core concerns I raised in my original post: the reliance on manual domain validation, and an incident response philosophy that blames humans instead of addressing root causes. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
