This request is to include the "ComSign Global Root CA" root certificate, and enable the Websites and Email trust bits. This root will eventually replace the "ComSign CA" root certificate that is currently included in NSS, and was approved in bug #420705.

ComSign is owned by Comda, Ltd., and was appointed by the Justice Ministry as a CA in Israel in accordance with the Electronic Signature Law 5761-2001. ComSign has issued electronic signatures to thousands of business people in Israel.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=675060

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8697333

Noteworthy points:

* The primary documents are the CP and CPS, provided in Hebrew and English. Only the Hebrew version of the CPS was approved by the Israeli CA Registrar. The English version of the CPS adds procedures dealing with SSL certificates, which are not regulated under Israel's Elctronic Signature Law.

Document Repository: https://www.comsign.co.il/
Document Repository (English): https://www.comsign.co.uk/?page_id=1282
CPS: http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf

* CA Hierarchy: This root has internally-operated subordinate CAs: ComSign ISA Global CA, ComSign Corporation CA, ComSign Professionals CA, and ComSign Organizational CA.
CA Hierarchy Diagram: https://bugzilla.mozilla.org/attachment.cgi?id=8608692

* This request is to enable the Websites and Email trust bits. ComSign is not requesting EV treatment at this time.

** Note: The English version of the CPS adds procedures dealing with SSL certificates, which are not regulated under Israel's Electronic Signature Law. So, the SSL verification procedures are only part of the English version of the CPS.

** CPS section 3.2.7.1: As part of the identification process, a unique secret code (the "Secret Code" will be mailed by Comsign to the Applicant's e-mail address. The Secret Code will be mailed during the coordination stage preceding the Applicant's personal appearance for the identification process. The Applicant will provide the Secret Code to the coordination clerk during the telephone conversation coordinating the Applicant's personal appearance. If the provided Secret Code is correct, the coordination clerk will transfer it to the identification clerk together with all other data pertaining to the applicant (including the applicant's e-mail address).

** CPS section 3.2.7.2: In the event of a non-coordinated visit to Comsign offices (as well as in any other event) the identification clerk will mail the Secret Code during the identification process (Comsign will provide the Applicant with internet access).

** CPS section 3.2.7.3. The Applicant must provide the Secret Code in the application form. The identification clerk will verify the matching of the Secret Code in the application form with the one reported by the coordination clerk (or by the applicant himself in a non-coordinated visit to Comsign offices) as well as the matching of the e-mail address in the application form with the address reported by the coordination clerk. Alternatively, the identification clerk will verify the matching of the Secret Code in the application form to the one mailed by the identification clerk to the e-mail address provided by the Applicant in the application form.

** CPS section 3.2.7.4: Only the e-mail address to which the verified Secret Code was mailed will appear in the electronic certificate issued by Comsign to the Applicant.

** CPS section 3.2.8.1: For issuing certificates to organizations requesting SSL certificates, Comsign performs domain name owner verification to detect cases of homographic spoofing of IDNs. Comsign employs an automated or manual process that searches various ‘whois’ services to find the owner of a particular domain. A search failure result is flagged and the RA rejects the Certificate Request. Additionally, the RA rejects any domain name that visually appears to be made up of multiple scripts within one hostname label. Note: Orders for major corporations, well known trademarks and financial institutions may be queued for further security reviews prior to issuance. In the event an order is queued for review the administrative contact must be a full time employee of the company for successful issuance. A verification telephone call with the administrative contact may be required.
- Verification methods include one of the following:
*** 3.2.8.1.1 EMail-based DCV
An email is sent to an administrative contact for the required domain. The email will contain a unique validation code and link. Clicking the link and entering the code will prove domain control. Valid email addresses are: Any email address listed in the "whois" records. The following generic admin type email addresses AT the domain for which the certificate is being applied: admin@, administrator@, postmaster@, hostmaster@, webmaster@
*** 3.2.8.1.2 DNS-based DCV
The CSR that Comsign receives from the Applicant will be hashed. The hash values are provided to the Applicant, and it must be entered as a DNS TXT record OR a DNS CNAME record for the domain. The hashes are to be entered in DNS RR as follows: CNAME Example: <Value of hash of CSR>.domainname.com CNAME <value of hash of CSR>.comsign.co.uk.
TXT Example:
DCV TXT <value of hash of CSR>
*** 3.2.8.1.3 HTTP(S)-based DCV
The CSR that Comsign receives from the Applicant will be hashed. The hash values are provided to you and you must create a simple plain-text file and place this in the root of your webserver and served over HTTP-only! The file and its content should be as follows: http://domainname.com/<Upper case value of hash of CSR>.txt
OR http://domainname.com/<Upper case value of hash of CSR>.html
Content (as a plain text file): <Value of hash of CSR> Comsign

** CPS section 3.2.8.2. Authentication of Organization identity
Before issuing SSL certificate and whenever a certificate contains an organization name, the identity of the organization and other enrolment information provided by Certificate Applicants (except for Non-verified Subscriber Information) is confirmed in accordance with the procedures set forth in ComSign’s documented validation procedures. Comsign shall: Determine that the organization exists by using at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization or an authorised lawyer that confirm the existence of the organisation according to local laws, confirm by telephone, confirmatory postal mail, or comparable procedure to the SSL certificate applicant certain information about the organization, that the organization has authorized the certificate application request, and that the person submitting the Certificate Application request on behalf of the certificate applicant is authorized to do so. Where a domain name is included in the SSL certificate - Comsign authenticates the organization’s right to use that specific domain name as a fully qualified domain name.

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=549246

* EV Policy OID: Not requesting EV treatment

* Test Website: https://fedir.comsign.co.il/test.html

* CRL URLs:     
http://fedir.comsign.co.il/crl/ComSignGlobalRootCA.crl
http://fedir.comsign.co.il/crl/ComsignOrganizationalCa.crl
CPS Section 2.3: The published list of revoked certificates is valid for 24 hours.

* OCSP URL: http://ocsp1.comsign.co.il

* Audit: Annual audits are performed by Sharony-Shefler, according to the WebTrust criteria.
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8599627
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8598250
EV Audit: Not requesting EV treatment
I have exchanged email with the auditor to confirm the authenticity of the audit statements.

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

This begins the discussion of the request from ComSign to include the "ComSign Global Root CA" root certificate, and enable the Websites and Email trust bits.

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

Reply via email to