Hi Ryan, Firstly, thank you for spending time and reviewing our work. Our answer to the two points you have stated is the following.
1) Domain Validation Methods > This section states "WHOIS records pertinent to domain name specified in > the certificate application shall be verified via 'www.nic.tr'". It would > be useful to have more detail on the validation method. See section 3.2.2.4 > of the Baseline Requirements. > - We realized that domain name ownership control via nic.tr is not > written in detailed. So, we updated related part in CPS. Please see 3.2.2 > part in CPS. > • To summarize, Domain Name Registrar is called by phone and contact > information of domain name registrant is checked whether it is same with > written in application form. If it is correct, Kamu SM requested an > agreed-upon change to information found on an online web page identified by > a uniform resource identifier containing the full domain name. So, > verification of domain name ownership is made by nic.tr. > >Note, as of adoption of Ballots 169 and 181 of the Baseline Requirements, >this no longer meets the sufficient bar for validation of control. >Please examine Section 3.2.2.4.6 of the Baseline Requirements. Our audit report was based on version 1.4.1 of the CA/Browser Forum’s Baseline Requirements and so we have reviewed this version of BR and planned our domain authorization validation method with respect to it. In chapter 3.2.2.4 of BR it was said that implementing at least one of the methods from 3.2.2.4.1 to 3.2.2.4.10 is enough for validation but we are implementing 3.2.2.4.1, 3.2.2.4.3 or 3.2.2.4.4, 3.2.2.4.5 and 3.2.2.4.6 for promoting validation. Note that, 3.2.2.4.5 and 3.2.2.4.6 are still active validation methods stated in v1.4.2. Let me briefly explain what we are doing in each step. 3.2.2.4.1: We are issuing OV SSL certificates only to government agencies and taking the application with the official letter containing the government agency seal. Nevertheless, we confirm it directly by communicating with nic.tr. "nic.tr" is the top level domain of Turkey, and holds domain authorization documents for all public institutions. The applicant representative for the certificate application on behalf of the government agency is determined by official correspondence between the Kamu SM and the government agency. Then it is checked that the applicant representative of certificate application is the person determined by official correspondence. 3.2.2.4.3 or 3.2.2.4.4: The applicant representative identified in 3.2.2.4.1 is contacted by phone or e-mail and the certificate request is confirmed. 3.2.2.4.5: Since we serve government agencies, the government agency that owns the domain can not change, but the applicant representative who applies on behalf of the agency can change. In this case, the government agency shall indicate to us the new representative with the official document as it was before, and it is required that the applicant representative in the certificate application document must be same with the official documented person. 3.2.2.4.6: Applicant representative is requested to change a web page hosted in certificate requested domain. That change is done by serving the file which we sent for this purpose. This method means Request-upon-change for us but until the next audit, we plan to use the request token method which is indicated in CAB BR section 3.2.2.4.6. Detailed verification steps are specified in CPS section 3.2.2. 2) Qualified audit statement listing serial number generation deficiencies for the time period from September 30, 2016 to when it was fixed by the CA 10.3 End Entity SSL Certificate Template > > For Serial Number, a unique number is insufficient, per BRs "CAs SHALL > generate non-sequential Certificate serial numbers greater than zero (0) > containing at least 64 bits of output from a CSPRNG." > > -Our random generator was not generating 64 bit number. Now, we changed > the procedure for creating serial number as: 64 bit random number is > generated by CSPRNG and concatenated with the number generated by sequence. > Our new test ssl certificate in https://testssl.kamusm.gov.tr/ was > created with such a serial number >As of Ballot 164 for the Baseline Requirements, this has been required for all >>publicly trusted CAs since 30 September 2016. >all publicly trusted CAs since 30 September 2016. Prior to CA/B BR v1.3.7, the certificate serial numbers are required to contain at least 20 bits of entropy. We were satisfying this condition by adding 32 bits entropy to the serial number. We had implemented the 64-bit entropy restriction beginning with v1.3.7 which went into effect on September 30th, but the system is left to add 32-bit entropy. As a result of Andrew's warnings, we have quickly deployed 64-bit random generator implementation and updated the test web page certificate to ensure this. There is no active certificate that we have issued since the process of our new root application has not been completed. Certificates that will issue after our application process is completed will provide this feature. Thank you for all your comments. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
