Thank you very much Devon for this analysis and the time past on our request.
You will find below additional information. Sorry for the delay, I was on vacation. The publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you. Thank you in advance for your help and your reply. ---------------------------------------------------------------------------- CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities." CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section. CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator" Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”? -> In the CPS, the term RA is mainly used for the registration authority, which rely on the DRA for some of its operations, such as collecting or issuing information to the certificate manager. However, we have made the choice for the moment that the majority of the verifications are currently carried out by our internal RA, and not the DRAs however some controls such as face to face can be ensure to the DRA. Paragraph 4.2.1 was added in particular to address this case where the face-to-face was in particular carried out by a DRA, however the other controls, in particular that concerning the control of the domain is well realized by the Certigna internal RA through technical means put in place by our services and not those of our DRAs. We can, if you wish, specify in our CP / CPS that these checks are carried out by the RA and not the DRA. For clarification, the control of the DRA operator mandate is to verify that the person who sends a proof (eg attestation of face to face) is among the authorized persons of the DRA and that the signature (handwritten or electronic) of the document comes from this person. ---------------------------------------------------------------------------- CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA. This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record: • CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21 • CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. • CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. -> Indeed, we were operating up to now a control with an alert and a notification to the applicant (pointing on this page https://www.certigna.fr/dns-caa.xhtml) to add us in the field CAA if that It is present, but it was not blocking for the request because we considered that having a signed authorization of the legal representative was sufficient even if the applicant not having updated the CAA registration. Now, our control processes foresee that the certificate request is blocked notably in the following cases: - The CAA DNS field is present, it contains an "issue" or "issuewild" tag and it does not list Certigna as an authorized CA. - The CAA DNS field is present, designed as critical and the tag used is not supported by the CA (so if it is not an "issue" or "issuewild"). We will be releasing the CP / CPS update to clarify these practices being implemented now. If this is enough for you, we will immediately publish the documents. ---------------------------------------------------------------------------- CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for determining high risk as well as additional vetting requirements are documented, however, I do not see this documentation anywhere. On what basis is a certification request deemed “high risk” and in what way, specifically, does this impact a subscriber’s ability to obtain a certificate? -> For each certificate request, we automatically perform a check via the Google Safe Browsing API and we also think about using the base of the organization "phishing initiative". If a URL goes back at risk by these databases, the certificate request is automatically rejected and the applicant is notified by email. We can specify these practices in more detail in our CPS if you wish, but we did not want to explain to much our procedures and the databases used because we felt that disclosing too much in detail our security practices to the public can help malicious people to adapt their request to try to circumvent our control devices. ---------------------------------------------------------------------------- Root CA CP Section 4.3.2: The delivery of certificate is achieved during the key ceremony, to a CA administrator authorized by CA and in charge of its exploitation and diffusion. Can you please explain what these sentences mean? This sub-section is cited as the response to BR Section 4.3.1 CA Actions during Certificate Issuance in the latest version of the BR self-assessment, but does not appear to speak to this requirement. -> Indeed, it is a problem of interpretation from us, we thought that it covered the delivery of the certificate of the root authority and not the issue of the end-entities certificates. The answer is available in the following chapter: "4.3.1. Actions of the CA concerning the delivery of the certificate After validation by the RA, the CA initiates the certificate generation process for the Certificate Manager. 4.3.2. Notification by the CA of the certificate to the certificate manager Complete and accurate certificate is made available to the Certificate Manager (on the customer area). The Certificate Manager authenticates to the customer area to accept the certificate or complete a paper form. " The document "BR assessment" has been updated to take into account all the evolutions mentioned above as well as this one. Do you want additional information on this point ? ---------------------------------------------------------------------------- As mentioned above, the publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you. Thank you in advance for your help and your reply. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
