Include Renewed Kamu SM root certificate

[Kathleen Wilson]

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:
…<snip>...
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 certificate, all information to be included in subject field of the certificate shall be verified as set forth in CA/B Forum Baseline Requirements document.
Verification procedures of Kamu SM shall be performed in compliance with the following steps:
• Head office address of the government agency requesting certificate and organization representative having applied for certificate shall be verified based on the legal documents. In addition to this, that
organization representative executing application procedures on behalf of the agency requesting certificate is entitled to apply for on behalf of the organization shall be verified with legal documents.
• Phone numbers submitted in application documents by the organization representative having applied for certificate shall be checked whether they match with legal records or not. The organization representative having applied for certificate shall be called from phone numbers verified accordingly and is requested to verify its application.
• It should be verified that e-mail address declared by organization representative having
applied for certificate during application is sent by the organization representative. This verification procedure shall be confirmed by a verification e-mail sent to e-mail address of organization representative.
• WHOIS records pertinent to domain name specified in certificate application shall be verified via “www.nic.tr”
• As a principle, applicant should have exclusive right and authority in regard to use of relevant domain name which is included in the certificate. This exclusive right and authority must be granted by registered owner or organization of domain name.
• Continuity of operation should be verified with a current official document to be submitted by organization representative or the persons authorized to issue an official document on behalf of government agencies.

* EV Policy OID: Not Requesting EV treatment

* Test Website: https://testssl.kamusm.gov.tr/

* CRL URLs:
http://depo.kamusm.gov.tr/ssl/SSLSIL.S1.crl
http://depo.kamusm.gov.tr/ssl/SSLKOKSIL.S1.crl
SSL CP/CPS Section 4.9.7: CRL for end-entity certs is valid for maximum of 36 hours.

* OCSP URLs
http://ocspssls1.kamusm.gov.tr
http://ocspsslkoks1.kamusm.gov.tr

* Audit: Annual audits are performed by Information and Communications Technologies Authority (ICTA) according to the ETSI TS 102 042 v2.4.1 criteria.
Audit Statement: https://bug1262809.bmoattachments.org/attachment.cgi?id=8819839
I received email from the auditor confirming the authenticity of the audit statement.
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1262809#c25

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the 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. At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then an additional discussion may be needed as follow-up. If there are no outstanding issues, then I will recommend approval of this request in the bug.

Kathleen

[tuuba...@gmail.com]

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 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

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 9:14 AM, tuubaonder--- via dev-security-policy <
dev-secur...@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.

[Kathleen Wilson]

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

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 6:01 PM, Kathleen Wilson via dev-security-policy <
dev-secur...@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.

[tugba onder]

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.

[tugba onder]

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

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 9:56 AM, tugba onder via dev-security-policy <
dev-secur...@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 :)

[tugba onder]

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.

[Ryan Sleevi]

On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy <
dev-secur...@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")

[tugba onder]

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,

[Ryan Sleevi]

On Tue, Mar 14, 2017 at 5:10 PM, tugba onder via dev-security-policy <
dev-secur...@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.

[Kathleen Wilson]

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

[Kathleen Wilson]

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