Hello Thank you for your exchanges. We hope that the additions below will answer your questions.
Was the action required to manually override the CAA validation failure different from what would be required if the CAA validation had succeeded? Could an operator have just "clicked the same button they always clicked", and have the CAA validation failure overridden? Or was there a separate sequence of UI interactions required to override a CAA validation failure? This answer does not address the controls in place at the time of the misissuance. Any action which an operator can manually take should be able to be audited for correctness, but I don't see any mention of that being a possibility in your response. I take that to mean that there are no functional audit logs, or at least that there are no effective audits (sampling or otherwise) of those logs, for decisions and actions undertaken by registration agents. The check on the authorization to be issued for the organization was the only one that combined both the verification of the consent form and the verification of DNS CAA alerts. The operator could view the alert but the same validation button was used to proceed to the next step, whether the DNS CAA is valid or not. Each operation performed by an operator is traced so that it can be audited. The periodic audits of registration requests are also intended to ensure the conduct of controls by RA and the conformity of their results. This sounds like there may have been a misunderstanding in the BR description of CAA validation. What specific language in the BRs surrounding CAA validation caused you to believe that successful CAA validation was optional in the presence of other forms of consent? What changes do you propose in the language of the CAA validation requirements in the BRs to ensure that no other CA could possibly misunderstand the CAA validation requirements? We have no improvement to issue regarding BRs. We understood the requirement and implemented the DNS CAA control but we made two errors: - The first is to have assessed that the existing control having the same purpose, made it possible to cover the risks and requirements related to the control of the DNS CAA. This decision led to wrongly allow RA operators to validate this checkpoint despite DNS CAA alerts. - The second is to have accumulated these two controls (consent + DNS CAA) in the same validation step because they had the same objective, and this without imposing that the DNS CAA negative result be blocking. Have you proposed those changes to the CA/B Forum, to improve the BRs for all participants? If not, why not? We would recommend to the other CAs to segment each control even if their objective is the same, in order to be sure that the result of each control is taken into account and can not be circumvented under the pretext that a control, having the same purpose, is positive. Regarding the control on obtaining the consent of the legal representative, it is imposed by a national standard that is gradually aligned with the guidelines of the CA\B Forum, but this standard unfortunately does not evolve quickly due to administrative constraints. We did not perceive the interest of suggesting the use of this method knowing that it is imposed only on the scale of France and not for other international CA and that the control of the DNS CAA had in our opinion the same purpose . We want as much as possible that the different national, European and international standards are harmonized in order to avoid the implementation of different controls but for the same purposes. That the BRs have been misunderstood in this fashion is somewhat concerning. it suggests that there may be other misunderstandings latent in your systems and processes, which haven't surfaced because they haven't (yet) led to an identified misissuance or other incident. What steps have you taken, or are you planning on taking, to address possible misunderstandings of the BRs or Mozilla policy that may cause Certigna to unintentionally misissue a certificate or suffer from some other incident? In what ways have you modified your monitoring, internal audits, and annual audits by a certification body in light of the fact that the previous editions of those were manifestly insufficient to identify the non-compliance of your CAA-related procedures ? To address the two errors mentioned above, we have updated the RA Validation Portal to separate the DNS CAA control and make it blocking automatically. The other validation steps are well separated. In addition to the audit we conducted following the DNS CAA incident, we are conducting the annual internal audit of our practices in order to verify, as each year, their compliance with the requirements of the BRs and EV Guidelines. It is also expected that new auditors will be involved, both in the internal audit and in the certification audit planned for this year. We also made aware and reminded the following points to all the actors of the organization and in particular the members of the security committee: - The incident encountered and its origins; - The need to ensure compliance with the requirements of the CA/Browser Forum; - The need to report any non-compliance or incident encountered in order to notify the Forum; - Update any changes to the self-assessment file to ensure compliance with the requirements; - The need to comply with each requirement even if it is considered that an already existing practice but different can cover the requirement. The communication process has been updated to specify in more detail how information is sent to the CA\B FORUM via the different portals available. The certification body in charge of our audit includes in these audit criteria the ETSI standards but also the BR and EV guidelines as we requested. As said above, new auditors are selected for our next certification audit. I'm also concerned by your use of the word "blocking" in this context. You say that "all controls results [...] are now blocking", which I would normally take to mean that there is no way that a registration agent would be able to influence the issuance of a certificate in contravention of your policies. However, in your answer to Q23 (which I've included below) you state that there are a number of validation checks which are performed manually, which (I presume, and please provide a detailed correction if I am wrong) would allow for a certificate to be misissued as a result of misunderstanding, mistake, or malfeasance on the part of a registration agent. Could you please explain further what exactly you mean by "blocking" in the context of your above answer? Controls are automatic such as DCV or DNS CAA and others are not and are manually performed by the operators as mentioned above. Whether the control is done automatically or manually, if the result of only one of these checks is negative, the request is "blocked" and can not be validated by a RA operator. No validation and authorization to be issued is possible by a RA operator if the result of one of the manual or automatic control points is negative. The request is in an "Invalid" state while waiting for corrections or proofs to be made to the request. I'm having trouble reconciling the first sentence in this response with the rest of it. How could you currently consider that your CPS *was* in line with the BRs and Mozilla policy if you know there was a material mistake in your understanding of those documents? Our CPS is not limited only to BR compliance but also to other security requirements, and we believe that the accumulation of existing controls with those of the BRs would serve to meet the objectives of the requirements in question. We are not only committed to taking control of the DNS CAA, but also to carry out the prior checking on the obtaining of the consent by the legal representative of the organization, these two points aim at feeding the control on the authorization to be issued by the organization. So to answer you, yes the practices documented in our CPS were not exactly those presented by the BRs, but this results from the fact that we have additional practices to those expected by the BR and sincerely we thought that this set allowed to answer to BR expectations. We are now aware that the implementation of additional measures from other standards is not an exception and should not affect the implementation of the controls required by the BRs and that is why the control of DNS CAA is now independent of any other step of validation and control, and if its result is negative the validation of the request is blocked. As far as I am aware, the CA/B Forum is not required to follow Mozilla tickets, and thus I don't think that that constitutes informing the CA/B Forum. Indeed, it has not been reported by us, and we apologize for it because we sincerely thought that all our practices could meet the requirements on this point. Following the recovery of this non-compliance, we conducted an audit to identify any problem that led to the identification of this certificate. We are now aware of the need to improve our processes and have strengthened our communication procedures to ensure a report of non-conformities and incidents identified, as well as possible evolutions and practices that we would like to suggest to the forum. We remain at your disposal if you want further information. Best regards _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
