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
