On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via dev-security-policy wrote: > 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.
I'm afraid I don't see how this has any bearing on a failure to properly validate CAA records, as required by the BRs and Mozilla policy. If it helps simplify your answers, though, I think you could limit yourself to addressing issuance controls within the scope of the BRs and Mozilla policy, without reducing the utility of your answers to this group. > 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. Sorry, but I can't seem to find an answer to either of the above questions in your response. I can't find any description (or even allusion) to user experience, nor any details of the risk analysis process around CAA override functionality. > 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. Sorry, but I can't seem to find an answer to the above question in your response. I would expect to see a list of BR-required validations. > 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. It's the parts of the validation process that don't fall under that most eminently non-specific word "mostly" which are of primary concern. > 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. Proof of consent is not a control against misuse. Failure to properly validate CAA is in itself misissuance, regardless of whether or not the correct organization received the certificate. Running a red light is still an offence, even if you didn't have an accident. > 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. Are you saying that you don't account for the risk of possibly issuing a certificate in contravention of the BRs and Mozilla policy? > 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. I'm afraid I cannot see that. > 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. Do you consider that this CPS was in line with the BRs and Mozilla policy? If so, can you expand on your reasoning, and if not, why did you consider it appropriate to operate to a CPS that did not fully account for your obligations under the BRs and Mozilla policy? > 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, That's certainly the sense I'm getting. It seems that the core problem is that your organisation appears to take compliance with the BRs as something of a "nice to have", rather than a "must have". This raises the question of what other elements of the BRs you aren't adhering to, but just haven't tripped over yet, which my questions were attempting to identify. > 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. Based on what you've provided so far, I'm afraid I can't see how you come to that conclusion. CAA records indicate consent to issue for a specific CA or list of CAs given by the party in control of the DNS for a domain. Nothing you've described appears to be equal to or a strict superset of that. At any rate, though, the BRs require you to validate CAA records, not "validate CAA records or do something else the CA thinks is just as good", and it appears that you systematically failed to do so. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
