On Tue, Mar 7, 2017 at 9:14 AM, tuubaonder--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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. > 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. It is reasonable to expect this to be a qualification on the matter of opinion during the next annual audit that covers the period of time between 30 September 2016 until now. Given these two issues above, please ensure that the current Baseline Requirements v1.4.2, are reviewed by your CP/CPS team, and that all practices Kamu SM employs are consistent with these requirements. Please further ensure that any deviations from such requirements are acknowledged, either on this list or in the bug, and then sufficiently called out within the next audit period. Kathleen, might I suggest that we delay further progress until Kamu SM has had the opportunity to complete such a review and disclose any further inconsistencies to Mozilla, so that Mozilla may evaluate whether or not they represent blocking concerns towards the inclusion of this certificate, and to review with Kamu SM the proposed remediation steps? I think Kamu SM has shown a good faith effort to respond to the concerns raised, but I'm concerned that both of these recent developments within the CA/Browser Forum were overlooked, thus it may be best to hold onto proceeding until that comparison is done and disclosed, allowing the community sufficient information to respond - much as we see with the recent misissuance reports from existing trusted CAs. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
