On Sun, Sep 16, 2018 at 03:07:44PM -0700, josselin.allemandou--- via dev-security-policy wrote: > > 1. Can you explain in more detail the user experience of the RA interface > > which was used to misissue this certificate? Specifically, did approval > > of the issuance in the face of a CAA validation failure require a positive > > acknowledgement and override of the CAA validation failure, separate and > > distinct from the actions required to issue a certificate which passed CAA > > validation? > > The interface used by registration officer is dedicated to the processing > of certificate requests and is accessible with strong authentication with > a smartcard certificate. Via this interface, registration officer > operates and runs all the required checks for each FQDN requested. All > the manual controls to achieve are successively presented to the > registration operator so that he operates and acknowledges the validation > of each control. The results of automatic checks, such as CAA DNS and > DCV, are also presented to the operator in the validation workflow. > Previously, the CAA DNS control was the only one that was an alert and not > a blocking element for validating the request. The interface has been > fixed and the negative CAA DNS control result now blocks request > validation as for other controls.
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? > We made an error regarding CAA DNS control and the fact that its result is > not blocking for validation. We assessed during the risk assessment that > the form of consent of the legal representative, and the control of the > CAA DNS with a warning prompted to the registration officer, would be > sufficient to limit the risks of obtaining the consent of the > organization. This certificate issuance showed that we should have set up > an automatic block as soon as the implementation of the control. Now the > automatic blocking is active and the wrong results of all controls are > blocking. 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? Have you proposed those changes to the CA/B Forum, to improve the BRs for all participants? If not, why not? 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? > 4. Which other parts of the issuance process have been modified as a > result of the review of those risk analyses, in light of the failure of > the risk analysis around CAA override to correctly control for the > misissuance risk inherent in CAA override functionality being available to > RAs without sufficient compensating controls? > > 5. What compensating controls *were* in place to prevent misuse of this > manual CAA override? > > All controls results, manual as well as automatic, are now blocking for > validation of a request. Only the CAA DNS control was not blocking. The > risk assessment did not lead to action on the other controls. From now > on, even if the control methodologies differ from one set of requirements > to another, we will automatically ensure that validation is automatically > blocked until all controls are positive, even if the risk is considered to > be covered. by one of the methods used, and this also to ensure > compliance. It should be noted that control of consent is the only point > on which control practices were heterogeneous in our normative > requirements. For the other controls, the methodologies used are > homogeneous. 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. 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? > 23. Which validation controls listed in your CP / CPS are not fully > enforced by automated systems? (Your answers suggest at least one, so > make sure your answer is complete). > > The following controls always involve manual control by a registration > operator. The interface allows registration operator to track and confirm > the validation operations they perform and their results. These manual > controls relate to: > ⦁ The entity identity validation; > ⦁ The identity validation of the Certificate Manager and the legal > representative; > ⦁ The validation of the certificate application form with the signature of > the Certificate Manager and the legal representative; > ⦁ The realization of face-to-face with the Certificate Manager and telephone > calls; > ⦁ Validation of the identity of servers when it is a client server; > 13. Did or Do you consider that this CPS was in line with the BRs and > Mozilla policy? > > Yes. We consider that our CPS was and is in line with the BRs and Mozilla > policy. As mentioned earlier, we have implemented CAA DNS control as > required. We mistakenly felt that the control of the consent of the legal > representative, which is blocking it, and the addition of alerts related > to the CAA DNS control would meet the requirements. 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? > 20. Have you informed CAB/F about the specific situations in questions 17 > to 19 above. > > These points were exchanged as part of the referencing of our new root and > this led to the creation of this incident ticket. If we had identified > other cases following our audit, we would have also declared them in this > ticket. 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. > 21. Are there any other places where your CP / CPS do or did fall short > of the BR requirements? > > 22. Are there any places where your CP / CPS do or did fall short of > Mozilla requirements beyond the BRs? (This wasn't one, it was a BR). > > We currently have not identified any other areas that may be subject to > non-compliance. We regularly monitoring our practices to ensure > compliance and you will see that we are regularly updating our practices > and CP / CPS in line with the evolutions of BRs. In addition to these > controls, our internal audits and annual audits by a certification body > help to verify the compliance of our practices and documentation. 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? - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
