Hello,
Thank you for your contribution. We hope that the returns below will allow you
to better understand our past practices that led to the creation of this ticket.
It is important to remember that our CA is also subject to compliance with
national standards (e.g. RGS) which are more stringent for some controls than
ETSI standards or BRs. These standards require us, in particular, that each
certificate request be signed by the legal representative of the organization,
and that the identity document copy of the latter be collected and verified in
connection with the application. This control entails the collection of
evidence of the consent of a legal representative of the organization for us to
issue a certificate, while CAA DNS setup can be done by a technical manager,
even without having been validated by the organization itself.
So we were already asking for the consent of the organization for each request,
and we have added the CAA DNS controls and alerts both for compliance to the
CA/Browsers Forum, but also to trace incompatibilities with the declared wishes
of the organization.
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?
Our Registration Authority has a dedicated application for request management
and step-by-step validation of certificate applications. The addition of
technical controls is gradually reducing the human intervention of RA
operators, which now only concern the validation of supporting documents and
controls operated by face-to-face or by telephone. We are currently working to
automate some of these controls. Nowadays, the checks of domain control and DNS
CAA records are automatic and block requests.
3. What other parts of the issuance process have had a similar risk analysis
undertaken with similar initial results?
As mentioned above, the practices implemented in addition to the DNS CAA alerts
already provided the consent of the organization, which is why, while waiting
for the development of an automatic locking process, we had positioned an alert
to RA to identify any incompatibilities of authorization. It should be noted
that for the certificate object of this incident, the organization had already
given its formal consent and had been notified by email of the need to update
its DNS configuration.Risk assessments are conducted annually on these
processes and each process evolution is validated during security committees.
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?
There have been no other changes to our processes, the other controls being
mostly automatic.
5. What compensating controls *were* in place to prevent misuse of this manual
CAA override?
As mentioned above, the consent of the organization was already obtained in
another form, that imposed by our national requirements. Alerts sent by the
control of DNS CAA records should highlight inconsistencies in the
authorization statement, which automatically notify the applicant to update the
DNS configuration of the server, but for this unique case, the validation was
done before the applicant update its configuration.
6. In what specific ways did those compensating controls fail to properly
manage the risk?
It is difficult for each requirement to determine all the risks imagined by its
editor. If the risk is to issue a certificate without the consent of the
organization, in this case the compensatory measures are sufficient from our
point of view. Afterwards, the risk assessment remains a very subjective
subject and that is why, we make contribute, as for each evolution of our
processes, all the teams via a security committee to validate the practices.
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?
As you can see, we are working to be totally transparent about our practices.
Thus, in the CPs linked to our old practices, we explicitly specify that we
allow ourselves to issue a certificate if we have previously obtained the
consent of the organization and this even if the DNS CAA record had not yet
been updated by the applicant. The instructions given to the RA operators were
initially aligned with this commitment, however, given the few alerts
encountered, the operators still blocked the issue until the records were
up-to-date and consistent. Thus, except for a certificate that was issued in
accordance with our CP / CPS, all the others were subject to greater control
than we had committed.
Nevertheless, in addition to the training and awareness operations carried out
regularly, following this incident, we sensitized and re-trained all the staff
of the RA on the practices and controls to be operated, and also on the
controls implemented automatically without possible bypass.
The problem does not relate to our training, and what was implemented was
finally better than what was stated in our CP / CPS. The problem comes from the
fact that we operate several controls having the same purpose, but whose
methods differ because emanating from different requirements standards.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
