On Tue, Sep 11, 2018 at 12:34:34AM -0700, josselin.allemandou--- via dev-security-policy wrote: > This failure is related to our old practices that led to a control of the > DNS CAA records with automatic alerts for the Registration Officers, but > the blocking of the certificate request was not automatic unlike today.
I have some questions surrounding this incident, the answers to which will, I hope, be useful in identifying the larger ecosystem risks which can be extrapolated from this incident, both for Certigna as well as other CAs who may have similarly at-risk systems and processes. 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? 2. What details can you share around the risk analysis that deemed it appropriate to deploy a system where human operators were able to override critical issuance controls without any oversight, approval, or subsequent review of that override? 3. What other parts of the issuance process have had a similar risk analysis undertaken with similar initial results? 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? 6. In what specific ways did those compensating controls fail to properly manage the risk? 7. What training were RAs given in the policy and procedures surrounding CAA validation and the circumstances in which manual override of a CAA denial was appropriate and valid? 8. What aspect(s) of the training that RAs were given have been identified as being deficient, such that the RA determined that the action they took was appropriate? 9. What other aspects of the issuance process are trained in a similar manner to the CAA override training that was delivered? 10. In what specific ways has the training for those other aspects of the issuance process been improved, as a result of identifying the deficiencies in those training packages? 11. Have all RAs been retrained in line with the revised training packages, and if not, by what date do you expect such retraining to have been completed? 12. If all RAs have not yet been retrained, what additional compensating controls have you put in place in the meantime to handle the deficiency in RA training? - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy