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




_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to