Re: Include Renewed Kamu SM root certificate
Hi Ryan, >My request was one of just taking a few days / a week to re-examine what >the current BRs are, using your knowledge of your policies and practices, >and make sure that all methods are consistent. For example, the 64-bits of >entropy, the aligned-with-3.2.2.4.6 method of domain validation, etc. That >your auditor did not flag these implies that your auditor did not do that >level of analysis, but that's also not surprising given the role/function >of auditors (some auditors do this as part of their engagements, some >auditors do not, and generally both are seen as complying with the >necessary level of professional duty; just the ones that do are better >auditors, and the ones that don't may miss stuff that finds them removed as >trusted auditors in the future) >Because we've seen some CAs argue that "You didn't explicitly say we had to >follow X in the BRs", I wanted to avoid that situation, by just making sure >Kamu SM warrants that "We've read the BRs 1.4.2, we've examined our >policies and practices, we believe they're consistent and apply" (or "We >identified items X, Y, Z that we are fixing by doing A, B, C") Upon your request, we re-examined the current version of CAB BR (v.1.4.2) with our CPS document that describes our way of doing business. We did this work under these main headings; Identity Proofing, Technologies, Life Cycle Management, Certificate Profiles and Auditing Requirements. We read all related titles in CPS and CAB Br 1.4.2. Besides, so as not to miss any amendment item stated in section 1.2.2 (Relevant Dates) of CAB BR v1.4.2. we have stated Kamu SM approach for each item. The table is in this link: https://drive.google.com/file/d/0B3Yp-DkgL_W-OTR3cWxuOE84bmM/view?usp=sharing As a result, we could not notice any major difference between our practices and CAB BR v.1.4.2. The minor differences stated in the table will be fixed as soon as possible and be ready for the next audit. We hope that our examination meets your request and if there exists any other point you want to know please do not hesitate to ask. Best regards, ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
Hi Ryan,
>Right, but the reason I highlighted this is that the audit noted
>conformance to v1.4.1, but the process you described wasn't consistent with
>v1.4.1. It's understandable that the auditable controls for 1.4.1 have not
>been developed, so I'm not particularly surprised that this wouldn't have
>been called out in the audit, but it did highlight a divergence between the
>statement as to how you validate domains and the stated compliance.
- Yes, our annual audit report states that we are in compliance with CAB Forum
1.4.1 and in CAB Forum v1.4.1 section 3.2.2.4 it states that:
"The CA SHALL confirm that as of the date the Certificate issues, either the CA
or a Delegated Third Party has validated each Fully-Qualified Domain Name
(FQDN) listed in the Certificate using at least one of the methods listed
below."
Here, the part that needs to be taken care is "validate using at least one of
the methods listed". Although we mentioned it in our previous response, I guess
you missed it; we do not make verification just with respect to 3.2.2.4.6. For
the further satisfaction of 3.2.2.4, we first apply 3.2.2.4.1, then 3.2.2.4.3
or 3.2.2.4.4 and then 3.2.2.4.5. Therefore, even if we do not implement
3.2.2.4.6 at all, we satisfy the condition "validate using at least one of the
methods listed" in 3.2.2.4.
While we are implementing 3.2.2.4.6, we generate the "Required Website Content"
concept described in ballot 169, including only the information that uniquely
identifies the subscriber without a random value or request token. This
practice comes from item 6 of section 3.2.2.4 of BR v1.3.7. The important thing
that should be noted here is, the use of random value or request token is
coming with ballot 169. The effective date for ballot 169 was 1 March 2017, and
the date on which we have received our audit report was December 2016, before
the effective date.
Although we satisfy 3.2.2.4 by implementing multiple choices at the same time,
we believe, not necessarily but additionally implemented current version of
3.2.2.4.6, even if it is not fully consistent with the latest version, will
bring more security than the case it was never implemented. But we will also
fix it.
Similarly, at the time audit report was produced, Section 10.3 ("End Entity
SSL Certificate Template") was not consistent with Section 1 (current BRs).
Throughout the Mozilla Root Certificate Program, we have tried to fulfill all
requests with great appreciation. We believe this program, its partners, public
reviewers and also CA communications serve in the name of ensuring the
security, applicability, and interoperability by forcing CA/B Forum BR and make
CAs' fix their inconsistencies, if there exists, according to the updated BRs'.
We have considered Andrew's warning in this manner and deployed early
implemented but not deployed 64-bit random number in serial instead of early
deployed 32-bit. If you consider any other inconsistencies, please inform us,
we will appreciate it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
Hi Kathleen, Our updated CP/CPS documents in Turkish and in English are now in our web page. Here are the related links: http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
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
