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 Wilson <kwil...@mozilla.com>
wrote:

> 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
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to