Hello Thank you all for your feedback for which we have tried to provide additional information below. Know that if necessary, you will also find the description of our practices through the following links: • our CPS : * Services CA : http://politique.certigna.fr/en/DPCcertignaservicesca.pdf * Wild CA : http://politique.certigna.fr/en/DPCcertignawildca.pdf • Our BR self-assessment file :https://bugzilla.mozilla.org/attachment.cgi?id=9007984
Wayne: Thank you. We linked the ticket to the bug as requested. Tyler Schroder: We confirm that the certificate in question is the one that Tyler identified. It was revoked and we updated our CP / CPS to clarify the changes made following the incident and to provide additional information on other practices. > 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. > 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? 6. In what specific ways did those compensating controls fail to properly manage the risk? > Are you saying that you don't account for the risk of possibly issuing a > certificate in contravention of the BRs and Mozilla policy? To clarify our risk assessment process. We perform a risk assessment on the perimeter of PKI at least once a year and before major changes. We employ an exhaustive methodology aligned with the EBIOS method and the guidelines of ISO/IEC 27005. Our risk management processes are audited both in accordance with the requirements of ETSI standards, BRs, but also ISO/IEC 27001, standard on which we are also certified. We therefore consider legal, regulatory, contractual and normative security requirements for the conduct of risk assessments, and therefore the risks of non-compliance with the requirements set out by the BRs. Our different risk assessments incorporate the analysis of risks related to the registration operator activities. The different iterations led to the establishment of the RA interface with a rigorous script to follow and to respect in order to limit any risk or non-compliance in the processing of requests. 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. 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. 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. 17. Which criteria were required under your old policy to override a CAA failure? (Besides rechecking after a DNS change by the applicant)? I realize these were only used once, but the incorrect criteria you had instructed your validation officers to use would be interesting to understand how this mistaken policy was created. As mentioned above, in addition to the automatic control of the CAA DNS, a blocking control is already carried out on the supply of a certificate request signed by the legal representative of the organization, with the provision of a copy of his identity document. 18. How many certificates were delayed until the customer changed their CAA records? The only identified blocking cases corresponded to typographical errors in the registration of Certigna autority name (example: certignia.com, certgna.com, ...). After CAA DNS records were updated, theses certificates has been issued. 19. How many certificates were not issued because CAA failed and was not corrected by the applicant changing their DNS? As a result of our audit, other than the certificate identified by this incident and the cases listed for question 18, we have not identified any other case where the CAA DNS control should have been blocking. The majority of our certificates are issued under group contracts or public contracts for which the conditions of delivery and the obligations are known by the applicants even before placing their orders online. As a result, the majority of requests are received the first time with a valid DNS CAA record (when completed) or without (DNS CAA record not used by applicants). 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. 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. 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; We are currently working to automate some of the controls mentioned above such as those on identity checks. 24. Your CPS for the Root and Wild CPSs as of 8/31/2018 note in section 4.2.1 that a certificate issue that did not comply with RFC6844 would be automatically blocked. Your note in the first post says that "our new practices that automatically block any certificate request for which the DNS CAA record controls induce that the CA is not allowed to issue, without possible bypass by the RA". Was this blocking process not fully automated as described prior (going off of Q23 from Jakob)? Indeed, we have updated our CP and CPS to specify that the DNS CAA negative results automatically blocks the issuance of the certificate, which was not the case at the time of the occurrence of this incident. 25. What exactly prompted the manual override for CAA Checking? A request from the origin certificate requestor, the RA on their own... As mentioned above, we made an error concerning the control of the DNS CAA records 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 DNS CAA with a warning to registration officer, would be sufficient to limit the risks relating to obtaining the consent of the organization. The registration operator in charge of processing this request, finding that the DNS CAA error was not blocking, and having the consent in another form, performed the validation of the request. 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 results of all controls are blocking. We hope to have answered your questions and we remain at your disposal if you want more details. Best regards _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
