On Wednesday, August 22, 2018 at 2:10:06 AM UTC-7, josselin....@gmail.com wrote: > 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.
This would be a very good change, and it would address my concern. > > 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. I support these updates. Modulo addressing Wayne's concerns about past CAA practices, I'm comfortable with this language. > > ---------------------------------------------------------------------------- > 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. I don't think that will be necessary at this point; I just felt it would be beneficial to the public review of the application to define what actions are taken based on this risk assessment. > > > ---------------------------------------------------------------------------- > 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 ? My read here is that BR Section 4.3.1 stipulates a requirement on the issuance of certificates by the Root CA, while I feel the answer provided speaks to the issuance controls over leaf certificates from a subordinate CA, as I believe that under your terminology, a Certificate Manager is not involved in the issuance of CAs from a Root. I definitely appreciate the information about the issuance process for the leafs, but I believe the reason this section is included in the Self-assessment is to speak to controls around certificate issuance from the Root CA. > > ---------------------------------------------------------------------------- > > 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
