Re: Include Renewed Kamu SM root certificate
On Wednesday, March 15, 2017 at 9:56:25 AM UTC-7, Kathleen Wilson wrote: > Thanks to those of you who have reviewed and commented on this request from > the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include > the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and > enable the Websites trust bit. Thanks again to those of you who have reviewed this request, and to those of you who have participated in this discussion. I am now closing this discussion, and I will update the bug to recommend approval of this request. All further follow-up on this request should be in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 Thanks, Kathleen ___ 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
Thanks to those of you who have reviewed and commented on this request from the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable the Websites trust bit. I believe that all of the questions and concerns that have been raised in this discussion have been resolved. If there are no further questions or concerns about this request, then I will close this discussion and recommend approval in the bug. Thanks, Kathleen ___ 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
On Tue, Mar 14, 2017 at 5:10 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > Fantastic! I really appreciate you taking a second look, and I'm glad the extent of the misalignment was limited to the previously identified sections. I think that should be sufficient information to proceed. ___ 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, >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
On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > You're right, I did miss it / misunderstand. It's the first case I've heard of CAs applying multiple checks in an additive fashion; I've only ever heard of multiple layers being applied :) > 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. > Right, this was less a concern for misissuance, and more a concern for what we've seen a number of CAs do - which is fail to stay up to date relative to the changes. Your description of your validation after March 1 was inconsistent with 3.2.2.4.6, which is why I flagged it. If you've already validated the domain using a different form permitted, and 3.2.2.4.6 is just a secondary layer of validation, then I agree, it's no concern. It's only if you use the process you describe as the primary validation - if so, it must conform to 3.2.2.4.6, or you must use some other form of primary validation. > If you consider any other inconsistencies, please inform us, we will > appreciate it. 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") ___ 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
On Wed, Mar 8, 2017 at 9:56 AM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > 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. To me, it signaled that there may be other places where the asserted compliance is to v1.4.1, but the absence of audited criteria relative to the changes in v.1.4.1 may not have actually been implemented. The serial number is another example of that - where the practice and statement diverged. Here's another example: Section 2.2 of the Baseline Requirements requires that the CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. (and then describes an illustrative examples of fulfilling that obligation) Rather than including that clause, Section 1 of your CPS states "Kamu SM conforms to the updated versions of the standard ... and CA/Browser Forum Baseline Requirements (BR) for the Issuance and Management of Publicly Trusted Certificates". This is all perfectly fine and compliant with Section 2.2 - you've made the statement and represented adherence. However, the matters of both serial numbers and domain validation (as described) are examples of non-adherence to that Section 1 of your CPS, because the procedures used weren't consistent with Kamu SM conforming to the updated version of the standard. So that's why I suggested that you carefully examine the updated version for any other divergences. For example, the Mozilla community would not have been aware of the non-compliance to 3.2.2.4.6 had you not shared details, which is why Andrew originally requested them. There's the possibility of other areas of non-compliance, hence the similar request to fully examine the Baseline Requirements and double check to make sure all policies/processes are consistent - since Section 1 of your CPS says they will be, but it was determined they weren't. Once you've done that examination and identified any other issues, I was suggesting sharing those. That way, the community can know that we're "starting" from a good and compliant state, and then moving forward. It also avoids any issues where, if three years down the road we find something was overlooked, there's no way to excuse that - as there was the opportunity now to examine and comply. As it stands right now, Section 3.2.2 is in conflict with Section 1. I think that needs to be fixed. > 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. > Similarly, at the time audit report was produced, Section 10.3 ("End Entity SSL Certificate Template") was not consistent with Section 1 (current BRs). With your current update, this is resolved, although the matter still remains for Section 3.2.2 above. Further, given these, I'm suggesting it would be good to review your policies and practices for consistency with/adherence to Section 1 (or, more aptly, to the Baseline Requirements), share if there are any further inconsistencies identified, and then continue with the discussions :) ___ 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
Re: Include Renewed Kamu SM root certificate
On Tue, Mar 7, 2017 at 6:01 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 1) Domain Validation Methods > For the CA, I recommend reviewing section 3.2.2.4 of version 1.4.1 of the > CA/Browser Forum’s Baseline Requirements, because many of the relevant > subsections are currently redacted in version 1.4.2 due to ongoing > discussions in the CAB Forum. Nevertheless, the CA can review version 1.4.1 > to further bolster their domain validation policies and practices. > > I am hoping that the CAB Forum will resolve the issues that caused the > redaction of some sections of the BRs, such that a new version will be > published by the end of March that has the same level of information about > domain validation as version 1.4.1 of the BRs. > > Gerv and I plan to send a CA Communication around the end of March, and > plan for one of the action items to require that CAs update their CP/CPS, > because it should be updated annually. And also to update their domain > validation practices and policies. > While this applies to the overall process of domain validation, I was calling this specific matter out as it was the original motivation for the work presented three years ago, in part due to the security concerns Google raised to the Forum regarding it. That is, the practical demonstration of control for the server is one of the non-redacted/placeholder versions, so the description of file-based control should at least be reformed to this degree of 3.2.2.4.6, since it's hard to justify any other file-based control meets the equivalent level of security under 3.2.2.4.11 > 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. > > There is a lag between when a BR is updated/adopted, and when the audit > principles/criteria are adopted. So, I am not convinced that an audit > during that time period would cover that particular control, and list it as > an exception in the audit statement. > Correct, while it's unlikely that a specific illustrative control and/or new principle will be introduced on this regard, even when the WebTrust for CAs - SSL Baseline Requirements are updated to incorporate that version of the Baseline Requirements, it is a failure with respect to the CA's statement that the policies and practices outlined in the latest published version of the Baseline Requirements supercede that of the CP/CPS , which is where the qualification would be derived from. That is, CAs are expected to conform to the Baseline Requirements as they're updated/adopted, but there may not be auditable controls attached to them until one or two years after the passage, depending on the WebTrust TF or ETSI meeting to incorporate such requirements explicitly. However, they are all normative implicitly, per the stated adherence to the Baseline Requirements. ___ 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
Thank you Andrew and Ryan for your feedback on this request to include the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable the Websites trust bit. Note that the new SHA-256 root certificate will replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3” root certificate that is currently included, but expires on August 21, 2017. So, this CA will greatly appreciate prompt feedback from everyone. I have attached the updated version of the CPS (v1.0.1) to the bug: https://bug1262809.bmoattachments.org/attachment.cgi?id=8844549 Of course, all of this CA’s CPS changes will need to be propagated back to the Turkish version of the CPS, and to the CA's website. But let's see if there is any further feedback first. Andrew, does the updated CPS fully address your questions/concerns? Ryan, in regards to your feedback: 1) Domain Validation Methods For the CA, I recommend reviewing section 3.2.2.4 of version 1.4.1 of the CA/Browser Forum’s Baseline Requirements, because many of the relevant subsections are currently redacted in version 1.4.2 due to ongoing discussions in the CAB Forum. Nevertheless, the CA can review version 1.4.1 to further bolster their domain validation policies and practices. I am hoping that the CAB Forum will resolve the issues that caused the redaction of some sections of the BRs, such that a new version will be published by the end of March that has the same level of information about domain validation as version 1.4.1 of the BRs. Gerv and I plan to send a CA Communication around the end of March, and plan for one of the action items to require that CAs update their CP/CPS, because it should be updated annually. And also to update their domain validation practices and policies. 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. There is a lag between when a BR is updated/adopted, and when the audit principles/criteria are adopted. So, I am not convinced that an audit during that time period would cover that particular control, and list it as an exception in the audit statement. Thanks, Kathleen ___ 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
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
Re: Include Renewed Kamu SM root certificate
Hi Andrew and Kathleen, Thanks Andrew for reviewing our CPS document. We have updated the CPS document by the direction of your indications. Also you can find our replies below: 1.2 Document Name and Identification Document version number is 3, but the front page and headers say version 1. Please clarify. - Just misspelled. In fact it was 1.0.0. It is corrected and version history table is added and after theese changes it is updated as 1.0.1. Please see, 1.2 section of CPS. 3.1.5 Uniqueness of Names - Yes, usage of common name is Deprecated (Discouraged, but not prohibited) in CAB BR. Also, it is specified as “If present, this field MUST contain a single IP address or Fully‐Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension”. Firstly we want to indicate that we follow this rule and it can be checked via our test ssl certificate deployed on https://testssl.kamusm.gov.tr/. Also, we started work to remove common name in certificates and plan to complete it as soon as possible. 3.2.2 Authentication of Organization Identity 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. 4.9.3 Procedure for Revocation Request The Baseline Requirements for this section state: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means." - We have written the procedure of revocation in this section. However, as you said, how to apply for revocation should also be written. For this, we updated this section in CPS with the reference to “SSL Certificate Revocation Form” which you can find in our web page in this link: (http://www.kamusm.gov.tr/dosyalar/formlar/FORM-001-009%20GUVENLI%20SUNUCU%20SERTIFIKASI%20(SSL)%20IPTAL%20BASVURU%20FORMU.doc ) and all the instructions are in that form. The form is in Turkish, sorry for that, but our all applicants are Turkish government agencies as you know. As such instructions aren't included in the CP/CPS, could you point to where they can be found? 6.5.1 Specific Computer Security Technical Requirements Please make sure use of anti virus is properly risk managed. There have been a worrying number of high severity bugs in popular anti virus software, including privileged remote code execution. - We updated that section by adding that we keep the updateness of our virus detection systems and cleaning agents. Also, we can mention about our anti-virus security solutions. In our organization, host intrusion detection system is used besides antivirus security solutions for server and end user computers in the scope of security solutions. Security vulnerabilities of antivirus software are monitored and regular updates are made. In addition, the host intrusion detection system keeps track of user transactions under policies and informs the information security team by creating alarms for critical file movements, unauthorized access and abnormal movements. 7.2.2 CRL and CRL Entry Extensions Though optional, CRL reason codes are encouraged. - We was following the rule in section 5.3.1 of RFC 5280. Which indicates that the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. In fact we use reason code but the related entry in CRL profile was left optional accidentally. You can check an example CRL containing reason code from http://depo.kamusm.gov.tr/ssl/SSLSIL.S1.crl Also we updated the CPS section and removed optional. 9.4.3 Information Not Deemed Private The contents of publicly trusted certificates should always be treated as public even if such a an agreement or contract is in place. - We updated that section, remove the condition. Now, we indicate The contents of publicly trusted certificates are not confidential. 10.3 End Entity SSL Certificate Template For Serial Number, a unique
Re: Include Renewed Kamu SM root certificate
Hello, I've read though the English language version of CP/CPS dated March 30, 2016 version 1 and made the following notes: No version history at the front of the document. This not required, but is evidence of good document change management and is a useful reference to see what's changed when coming back to reviewing docs. 1.2 Document Name and Identification Document version number is 3, but the front page and headers say version 1. Please clarify. 3.1.5 Uniqueness of Names CN Field: Note that use of the common name is deprecated. 3.2.2 Authentication of Organization Identity 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. 4.9.3 Procedure for Revocation Request The Baseline Requirements for this section state: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means." As such instructions aren't included in the CP/CPS, could you point to where they can be found? 6.5.1 Specific Computer Security Technical Requirements Please make sure use of anti virus is properly risk managed. There have been a worrying number of high severity bugs in popular anti virus software, including privileged remote code execution. 7.2.2 CRL and CRL Entry Extensions Though optional, CRL reason codes are encouraged. 9.4.3 Information Not Deemed Private The contents of publicly trusted certificates should always be treated as public even if such a an agreement or contract is in place. 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." -- Overall the document was clear and well written and didn't contain anything too worrying. Cheers, Andrew On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilsonwrote: > This request from the Government of Turkey, Kamu Sertifikasyon Merkezi > (Kamu SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum > 1” root certificate, and enable the Websites trust bit. This SHA-256 root > certificate will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika > Hizmet Sağlayıcısı - Sürüm 3” root certificate that was included via > Bugzilla Bug #381974. The old root certificate expires in August, 2017. > > Note that the CA has indicated that since Kamu SM is a government CA , the > CA only issues certificates to government-owned domains (restricted by > these TLDs: gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr > and org.tr ) and does not issue any certificates outside of Turkey. So, > Mozilla may constrain this root to those domains. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967 > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=8738995 > http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer > > * The primary document, the SSL CP/CPS, is provided in both Turkish and > English. > > Document Repository: http://depo.kamusm.gov.tr/ilke/ > SSL CP/CPS: > http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf > http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf > > * CA Hierarchy: This root certificate has internally operated subordinate > CAs that issue SSL end-entity certificates. > > * This request is to turn on the Websites trust bit. > ** SSL CP/CPS section 3.2.2: Authentication of government agencies having > requested OV SSL certificate from Kamu SM shall be performed by way of > verification from official correspondences made between Kamu SM, relevant > government agency and relevant channels of domain ownership (e.g., nic.tr > ). > All applications made to Kamu SM shall be supported with legal documents > that shall authenticate the following information and some of this > information shall be included within the Subject field: > …... > Residence address of applicant government agency is taken as a basis in OV > SSL applications. Legal status, identification information, domain name, > organization representative, presence of application, CSR information and > other similar information of applicant should be verified. Since the > organization authentication is of high importance while issuing OV SSL >