On 12/10/15 12:01 PM, Kathleen Wilson wrote:
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
Does anyone need more time to review this request from ComSign to
include the "ComSign Global Root CA" root certificate, and enable the
Websites and Email trust bits?
If not, and no one has any questions/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
