675060 - Add Comsign Global Root CA certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

Attachment: Comsign Global Root CA

Comsign is requesting inclusion of their new root certificate, with hash algorithm Sha256 with public key 4096.

Comment 1

[Kathleen Wilson]

Michal, Please provide further information regarding this root certificate. In particular, test website url, which trust bits to enable, SSL validation type, planned CA hierarchy, links to the relevant CP/CPS documents, and English translations of verification policies and practices.

Information Checklist: https://wiki.mozilla.org/CA:Information_checklist

Comment 2

[Michal Dor]

This root is going to replace our current root (Comsign CA - sha1 2048).
the cps is the same as the one used to authenticate the first Root.

we don't have end user certificate yet
but i can attached the intermediate if it will help.

Comment 3

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 4

[Michal Dor]

Thanks
Here is ny response :
1.we don't have end user certificate/ test website
 can i send you the intermediate so you can see the chain.
 we will have the test certificate soon.
2.CRL - we fix it - it wasn't pem format- try now
3.requested trust bit : Email
4.ca hierarchy: 
  Comsign Global Root ca 
    Sub CA :
    ComSign ISA Global CA
    ComSign Corporations CA
    ComSign Professionals CA
5. External Operated Sub CA - N/A
6.Croos Signing - N/A
7.code Signing - N/A
8.this Root is only for email signing - not for ssl so not relevent all the ssl questions.

Comment 5

[Michal Dor]

Attachment: new diagram

Comment 6

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 7

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 8

[Kathleen Wilson]

Please provide a test certificate and the intermediate certificates.

Do you have an audit report for this year that includes this new root?

Comment 9

[Kathleen Wilson]

Attachment: Intermediate Cert

Comment 10

[Kathleen Wilson]

Attachment: Test Cert

Comment 11

[Inbal Harel]

Attachment: Audit report

Audit report

Comment 12

[jz12345]

ComSign - a legitimate electronic signature certifier, or a large-scale con by the government of the State of Israel?

ComSign is a private corporation, which was established through a dubious process as the only certifying authority for electronic signatures, which is recognized by the State of Israel.  ComSign issues certificates of authenticity.  However, to this date, after reviewing thousands of judicial records and other legal public records of the State of Israel, a single visible certificate is yet to be discovered. At least one browser (Mozilla) is documented refusing to recognize SomSign certificates, for failure to produce audit records.  The evidence discovered to this date, does not enable one to discern: Is ComSign a legitimate electronic signature certifier, or a large-scale con on the People by the government of the State of Israel?  In effort to resolve the dilemma, sample digital certificates were requested from both ComSign and the Ministry of Justice of the State of Israel. The responses hold particular significance to Human Rights and banking regulation in the State of Israel.



As part of efforts to discern the nature of ComSign, LTD, and its conduct as sole certifying authority for the State of Israel, Joseph Zernik, PhD, of Human Rights Alert (NGO), has filed requests with the Ministry of Justice of the State of Israel [1] and ComSign, LTD, [2] for sample certificates of electronic signatures, pursuant to the Electronic Signature Act (2001).

Little noticed, unannounced regime change took place in Israel in the early 2000s with the passage and implementation of the Electronic Signature Act (2001), the new Regulations of the Courts -  Office of the Clerk (2004), and the concurrent implementation of new electronic record systems in the courts of the State of Israel: [3] 
The Electronic Signature Act (2001) established certified digital signatures for State officers and attorneys appearing in courts, and prescribed that a Magistrate Judge be appointed by the Minister of Justice, holding the office of "Registrar of Certifying Authorities", to oversee the implementation of the database of certified digital signatures.  However, Freedom of Information response by the Ministry of Justice states that no individual was appointed for a full decade, until 2011, to hold that office.  Regardless, individuals falsely appeared in the intervening years as "Registrar of Certifying Authorities" and conducted business on behalf of that office, promulgated guidelines, filed annual reports with the legislature (Knesset) and engaged in enforcement, all with no lawful authority. Through such conduct, ComSign, LTD, was established as the sole certifying authority of electronic signatures for the State of Israel.  With it, the digital seal of the State of Israel was effectively hijacked. [4] 
New electronic record systems were concurrently implemented in the courts of the State of Israel.  The 2010 State Ombudsman's Report 60b [5] documents that the systems were developed and implemented in violation of State law and regulations: 
The systems were developed with no specifications 
Development of the systems was delegated to corporations with no bidding (US-based corporations, IBM and EDS, were involved in this project) 
Development was conducted with no core supervision by State employees 
The systems were received with no independent testing by the State client. 
The servers, holding the records of the courts of the State of Israel were removed to corporate grounds, and are not under State control.  
The Regulations of the Court - Office of the Clerk (2004) were amended in 2005, in conjunction with implementation of the new electronic record systems in the courts. The amendment permitted the Director of Administration of Courts to modify the Regulations as necessary in the process of implementing the systems. [5]  The Director of the Administration of Courts has never published the modification that were introduced in the Regulations under such authority, and the Administration of Courts refuses to answer on any Freedom of Information requests, pertaining to the electronic record systems. [3] 
During the relevant period (2001-2012), seven (7) different individuals, affiliated with various political parties, served as Justice Ministers of the State of Israel: Meir Shitrit, Yosef Lapid, Tzipi Livni, Haim Ramon, Ehud Olmert, Daniel Friedman, and Yaakov Neeman. [14]

One of the notable features of the new electronic record systems is neither a single visible certified digital signature, pursuant to the Electronic Signature Act (2001), nor a single certified server has been discovered in recent review of thousands of public legal records.  [4]  All decisions of the Supreme Court are now published as electronic record, unsigned and uncertified, subject to "editing and phrasing changes", and the Supreme Court refuses to duly serve its decisions on parties to litigation. [3]

In parallel, the Human Rights Alert (NGO) 2012 report [3] documents the proliferation of simulated records in the Supreme Court of the State of Israel, conduct of simulated review of cases before the court, [6] and fraud in certification of decisions of Supreme Court by the Chief Clerk of the Supreme Court. [9] Falsification of records in the District Court in Tel Aviv was documented by the Israel Bar Association [8], and falsification of records in the Detainees Courts was reported by Haaretz daily. [10]

Separately, the Administration of Courts denied a Freedom of Information request for the appointment records of the Chief Clerk of the Supreme Court, claiming that is was a "record of internal deliberation." [9]

Several individuals, appearing under various titles,  were central to the fraud in implementation of the Electronic Signature Act (2001): 
1) Meir Shitrit 
2001-3 - Minister of Justice,  signed Electronic Signature Act (2001) and oversaw the first couple of years of its implementation; 
2) Yoram HaCohen 
- Head of the Justice, Information, Technology Authority; 
- Registrar of Databases in the Ministry of Justice; 
- Registrar of Certifying Authorities" pursuant to the Electronic Signature Act (2001). 
3) Amit Ashkenazi 
- Legal Counsel of the Justice, Information, Technology Authority; 
- Registrar of Certifying Authorities" pursuant to the Electronic Signature Act (2001). 
Of particular concern is in this context is the nature of ComSign, LTD, and its conduct as sole certifying authority for the State of Israel.

The ComSign Certification Practice Statement opens with the following: [11] 
1.1.1. ComSign’s electronic certificate issuing services have been created to 
support secured E-commerce and additional electronic services to 
provide a solution to the technical, business and personal needs of 
electronic signature technology users. ComSign is registered as a CA at 
the CA registrar as defined by the Law[Electronic Signature Act (2001)of the 
State of Israel - jz]and is acting as a reliable third party that issues, 
manages, and revokes electronic certificates according to these procedures. 
The English web site of Comsign states under "Solutions", "Electronic Signatures": [11] 
Electronic signatures 
In the last decade, the ability to transfer data electronically has developed enormously. One of the key problems in developing transfer technology is authenticating the web surfer - the identity of the specific person who has performed an action on the internet cannot be known. This inability to identify prevents innumerable entities from providing services via information transfer technology and thus many procedures are still "stuck", cumbersome and bureaucratic. 
Electronic signatures have existed for many years already, and in 2001 the Knesset even passed the Electronic Signature Law, which reduced the gap between the authorities from the legal aspect and the existing technology. 
An electronic signature is an encrypted file attached to a message or document which allows identifying its sender and guarantees that the original content of the message or document has not been changed since being signed, and if it has been changed, the reader will receive a warning that the document is not complete compared to the original document that was signed. 
Digital signatures are based on methodical theory and by using complex algorhythms they prevent break-ins and/or changes to a document without the knowledge of the document signatory/reader. 
How can we recognize a digitally signed file/message? 
One must ensure that the [] sign appears, which confirms that the message was signed electronically. 
However, the space, designated for the image of the "sign", was left blank.  Review of thousands of judicial records and other legal public records of the State of Israel failed to discover a single visible certified digital signature.

The English web site of Comsign state, under "Solutions", "SSL": [11] 
SSL 
Secure Sockets Layer (SSL) is a method of encrypting and protecting secure web pages. Secure pages are those where the communication between them and the browser is encrypted and the identity of the company or person representing the pages can be clarified. 
When a web surfer reaches a secure page, the lock symbol ( [] ) appears at the top and bottom of the browser, and sometimes it even makes a locking sound. 
These indicate to the web surfer that the page is secure. Double-licking the lock symbol while visiting a secure page will display the identity of the company that owns the secure pages. (When clicking on the lock, it is recommended to check the name of the company responsible for the encryption and not be tempted to give your details to just any ephemeral company which has fabricated an opportunity for themselves). 
In this case, the symbol of SSL is shown. However, review of the web pages of ComSign itself, of the courts of the State of Israel, and other Israeli government web pages failed to discover any web page showing the SSL sign.

Some light is shed on this case in correspondence from 2003-2012 between ComSign, LTD, COO, and Mozilla, the non profit browser maker, asking to have ComSign added to the Mozillas root CA store: [11] 
Comment 1Gervase Markham [:gerv] 2007-06-01 08:29:49 PDT 
- Do you offer OCSP service?
- Can you confirm you are, as you say, planning to issue EV certificates (http://www.cabforum.org)?
- Please also tell us how you comply with sections 8, 9 and 10 of our CA policy: http://www.mozilla.org/projects/security/certs/policy/ (the sections relating to audits). You say you are audited by the Israeli Ministry of Justice, but we would need to know to which of our accepted standards the audit was conducted, and to have published evidence of the occurrence of the audit. (The Verisign affiliation and the fact that you are in the Microsoft store are not relevant to this question.)
Thanks,
Gerv
Comment 2Gervase Markham [:gerv] 2007-06-27 08:04:02 PDT 
Mr Harei: Are you able to answer my questions? If not, the bug will be closed.
Gerv
Comment 3Ran Harel 2007-06-27 08:09:37 PDT 
Hi Gerv, sorry for the delay
1. We do not currently offer OCSP service.
2. We are not currently planning on issuing EV certificates.
3. Since all audits were/are conducted for the Israeli Ministry of Justice, they are in Hebrew, and so we are in the process of translating and notarizing them for this purpose. If there is any other way to get this approval please tell me.
Thank you,
Ran
Comment 4Gervase Markham [:gerv] 2007-06-27 08:41:09 PDT 
Ran,
It may well be useful to have your audit documents translated - but the key questions are:
- Who did the audit?
- To what standard (e.g. WebTrust, ETSI) was the audit done?
Are you able to answer these two questions?
Gerv
Comment 5 Gervase Markham [:gerv] 2007-08-15 08:08:47 PDT 
Resolving INCOMPLETE due to lack of input from reporter.
Gerv 
As of this date, ComSign is still listed on the Pending Requests List, although on April 8, 2012, the accountants office Sharoni, Shefler et al (CPAs) issued an audit statement. [11]  In contrast, Comsign does appear on the approved list of IBM and Microsoft corporations. [11]

It should also be noted, that when trying to open the root certificates of ComSign, Microsoft Windows issues a security warning: "Unknown Publisher".

The experience gained in Israel, relative to implementation of the Electronic Signature Act (2001) and the new electronic records systems of the courts, demonstrates: 
The Executive had no intention of complying with the Electronic Signature Act (2001); 
The Judiciary were intimately involved in the conduct related to undermining the integrity of court record in the State of Israel; 
The Legislative is not ready, willing, able to exert oversight - individuals fraudulently appeared and filed annual reports with the Knesset as "Registrars of Certifying Authorities", pursuant to the Act. 
"Given the involvement in recent years of senior officers of all three branches of government in undermining the integrity of the justice system of the State of Israel, the only conceivable solution is in the establishment of a Truth and Reconciliation Commission," says Joseph Zernik, PhD, of Human Rights Alert.

Events that have taken place in Israel over the past decade also demonstrate that the biggest hacking risk to government data systems is from 'inside jobs' by government officials, and that no government should be trusted with constructing such systems, absent adequate transparency and public oversight.  

The electronic record systems of the courts in the United States were compromised a couple of decades earlier. Today, fraud in the electronic record systems of the many of the states (SUSTAIN) and the federal (PACER, CM/ECF) courts is rampant. [12] 

Corruption of the courts in the United States is most notably seen in abuse of Human Rights and failing banking regulation. [13] 

Conditions that have been established in the State of Israel pose similar risks to Human Rights and banking regulation in the State of Israel.  Israeli computing and encryption experts, some of the best in the world, should hold a particular civic duty in the safeguard of Human Rights and banking regulation in the State of Israel in the digital era.

LINKS:
[1] 12-06-27 Freedom of Information Request on the Ministry of Justice in re: Certified Digital Signatures of Officers of the Ministry of Justice s
http://www.scribd.com/doc/98529841/
[2] 12-07-06 Request filed with ComSign, LTD, for sample certified electronic signatures of the State of Israel s
http://www.scribd.com/doc/99331565/
[3] 12-06-04 Human Right Alert's Appendix to Submission; 15th UPR Working Group Session (Jan-Feb 2013) - State of Israel: Integrity, or lack thereof, of the electronic record systems of the courts of the State of Israel 
http://www.scribd.com/doc/82927700/ 
[4] 12-06-25 PRESS RELEASE: Hijacking of the Digital Seal of the State of Israel
http://www.scribd.com/doc/98120110/ 
[5] 10-00-00 State of Israel - Ombudsman's Report 60b, Ministry of Justice Computerization (2010) p 693 Et Seq
http://www.scribd.com/doc/50624862/ 
[6] 04-11-25 Takanot Batey Hamishpat - Mazkirut (2004) // Regulations of the Courts - Offices of the Clerks (2004) (Heb + Eng)
http://www.scribd.com/doc/48770720/ 
[7] 11-12-19 Simulated Records, Simulated Litigation Enabled by the Electronic Record Systems of the Supreme Court of the State of Israel (English) s
http://www.scribd.com/doc/73239491/ 
[8] 12-04-16 PRESS RELEASE: Criminal Fraud Complaint Against SARAH LIFSCHITZ, Chief Clerk of the Supreme Court of the State of Israel, Filed Today With Israel Policehttp://www.scribd.com/doc/89681591/ 
[9] 12-04-10 The Judge Alsheikh Affair – “Reconstructed Transcript” in the Tel-Aviv District Court _ Globe
http://www.scribd.com/doc/90686541/ 
[10] 11-02-08 Dana Weiler: Court issues ruling, with quotes, from a nonexistent hearing - Haaretz
http://www.scribd.com/doc/48769638/ 
[11] 12-07-06 ComSign, LTD - sole certifying authority of electronic signatures for the State of Israel - compilation of corporate records
http://www.scribd.com/doc/99350885
[12] 11-07-06 Request filed by Windsor and Zernik with US Attorney General Eric Holder for Review of Integrity of Public Access and Case Management Systems of the US Courts
http://www.scribd.com/doc/59480718/ 
[13] 12-06-08 Courts and Judges as racketeering enterprises under RICO (the Racketeer Influenced and Corrupt Organizations Act) - key element in the current financial 
http://www.scribd.com/doc/96504009/ 
[14] 12-07-06 List of Justice Ministers of the State of Israel 2001-2012 _ Wikipedia 
http://www.scribd.com/doc/99346540/

Comment 13

[Kathleen Wilson]

I don't know what to make of Comment #12. It implies that the ComSign root certs aren't in Microsoft's program, but they are. 

Anyways, to provide a status on this request...
The request is to enable the email trust bit for this new root, but the new CPS doesn't seem to mention (I'm not finding it) verification that the email address to be included in the certificate is owned/controlled by the certificate subscriber.

Comment 14

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #13)
> Anyways, to provide a status on this request...
> The request is to enable the email trust bit for this new root, but the new
> CPS doesn't seem to mention (I'm not finding it) verification that the email
> address to be included in the certificate is owned/controlled by the
> certificate subscriber.

Michal, Do you have an update on this?

Also, I'm still waiting for a response from ComSign regarding the recent CA Communication:
https://wiki.mozilla.org/CA:Communications#July_30.2C_2013

Comment 15

[Kathleen Wilson]

Status:
- Response to the CA communication was received and recorded shortly after Comment #14 was posted.
- Need current audit statement. (Needed for the old root too.)
- Email exchanged in October indicated that Comsign is updating their CPS.

Comment 16

[Amos]

Hi Kathleen,

We will update the new cps version at Comsign's web site next monday.

We will contact you when it's updated.

Regards,

Comment 17

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 18

[Kathleen Wilson]

This request has been added to the queue for public discussion. 
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 19

[Eli Spitzer]

Hello Kathleen,

We would like to modify our CA inclusion request of "Comsign Global Root CA" as follows:
The trust bits should be these:
1. Websites
2. Email
3. Code

Thanks and regards,

Eli Spitzer | Information security & System Management | Comsign Ltd.

Comment 20

[Kathleen Wilson]

(In reply to Eli Spitzer from comment #19)
> We would like to modify our CA inclusion request of "Comsign Global Root CA"
> as follows:
> The trust bits should be these:
> 1. Websites
> 2. Email
> 3. Code
> 

Then please also provide the following information:

Test website URL -- see item 11 of https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate

Baseline Requirements audit statement.
https://wiki.mozilla.org/CA:BaselineRequirements

SSL Verification Procedures, as per #3 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Code Signing Subscriber Verification Procedures ad per #5 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Response to the list of potentially problematic practices: https://wiki.mozilla.org/CA:Problematic_Practices

Response to the list of recommended practices: https://wiki.mozilla.org/CA:Recommended_Practices

Comment 21

[Kathleen Wilson]

Attachment: WebTrust BR 2015

Comment 22

[Kathleen Wilson]

Attachment: WebTrust CA 2015

Comment 23

[Kathleen Wilson]

Attachment: 675060-CAInformation.pdf

I have entered the data for this request into Salesforce.

Please review the attached document, and provide corrections or updates by adding a comment to this bug. Also, there are two places where further clarification is request (search for NEED to find them).

Comment 24

[Eli Spitzer]

Attachment: Comsign CA Diagram.jpg

Updated CA Diagram

Comment 25

[Eli Spitzer]

Hello Kathleen,
The information in the attached case information is mostly correct. However, here are some corrections and clarifications:

General information about CA's associated organization
------------------------------------------------------
•	Company Website: https://www.comsign.co.uk

Technical Information about Root Certificate
--------------------------------------------
•	Root Certificate download URL: this link leads to a file with no extension. The extension should be .cer or .crt.
•	Revocation tested: The site “certificate.revocationcheck.com” is unable to parse our OCSP responses, even though they are properly formed and verified.
•	Root Stores Included In: Microsoft, Apple, Adobe.

CA Hierarchy Information
------------------------
•	CA Hierarchy: the root CA “Comsign Global Root CA” now includes four internally-operated subordinate CAs. I am adding an attachment which contains the updated hierarchy diagram.
•	Technical Constraint on 3rd party Issuer: No external person or RA exists who can cause the issuance of an SSL certificate.
The reference to “authorized representatives” in this section refers to means of merely verifying the identity of a certificate applicant by a representative (e.g. a qualified lawyer etc.).

Comment 26

[Kathleen Wilson]

(In reply to Eli Spitzer from comment #25)
> •	Revocation tested: The site “certificate.revocationcheck.com” is unable to
> parse our OCSP responses, even though they are properly formed and verified.

I asked the person who provides the certificate.revocationcheck.com site, and he responded as follows:

For fedir.comsign.co.il I get an Internal Server Error:

Unexpected HTTP response from 'http://ocsp1.comsign.co.il' (500 Internal Server Error)

With GET:

    curl -I http://ocsp1.comsign.co.il/MFIwUDBOMEwwSjAJBgUrDgMCGgUABBR7f2GN0VPh0vethi8ADMbwoRa8sAQUAkWT2A1IYqxpuq4GWz77qiaRULECEQCHtWNiRLZ01JlC%2BDPykKxM
    HTTP/1.1 500 Internal Server Error
    Content-Length: 0
    Content-Type: text/html
    Server: Microsoft-IIS/8.5
    X-Powered-By: ARR/2.5
    X-Powered-By: ASP.NET
    Date: Thu, 28 May 2015 16:07:22 GMT
    Set-Cookie: visid_incap_184418=83Ue1tB6QlCcf89VPYGt1D49Z1UAAAAAQUIPAAAAAABYWyrcKgBTxrfDHzlZFDaE; expires=Sat, 27 May 2017 14:17:15 GMT; path=/; Domain=.comsign.co.il
    Set-Cookie: incap_ses_128_184418=kMceAPRhS0s6qPflqr/GAT49Z1UAAAAAV6KXljwaoV/PYCOs8TLFeQ==; path=/; Domain=.comsign.co.il
    X-Iinfo: 7-25060221-25060222 NNNY CT(159 -1 0) RT(1432829246201 0) q(0 0 1 -1) r(5 5) U6
    X-CDN: Incapsula

With POST the response is not more then a "0":

    * Hostname was NOT found in DNS cache
    *   Trying 149.126.72.7...
    * Connected to ocsp1.comsign.co.il (149.126.72.7) port 80 (#0)
    > POST / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: ocsp1.comsign.co.il
    > Accept: */*
    > Content-Length: 114
    > Content-Type: application/x-www-form-urlencoded
    >
    * upload completely sent off: 114 out of 114 bytes
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Content-Length: 5
    < Content-Type: application/ocsp-response
    * Server Microsoft-IIS/8.5 is not blacklisted
    < Server: Microsoft-IIS/8.5
    < X-Powered-By: ARR/2.5
    < X-Powered-By: ASP.NET
    < Date: Thu, 28 May 2015 16:09:39 GMT
    < Set-Cookie: visid_incap_184418=2chHxeT2TAWEjhI5WJabuMc9Z1UAAAAAQUIPAAAAAADc/7fBl6Zn9kimDeQeNAzK; expires=Sat, 27 May 2017 14:16:13 GMT; path=/; Domain=.comsign.co.il
    < Set-Cookie: incap_ses_128_184418=hBdtLbVCYQfXHfjlqr/GAcc9Z1UAAAAAzTFmM2bAMK2K1dOj07zh0Q==; path=/; Domain=.comsign.co.il
    < X-Iinfo: 8-37439602-37439603 NNNY CT(149 -1 0) RT(1432829382708 1) q(0 0 1 -1) r(11 11) U6
    < X-CDN: Incapsula
    <
    0

Comment 27

[Eli Spitzer]

Hallo Kathleen, 

We reconfigured the OCSP server completely.
Still the website for checking the service is having trouble with the respnse:
The only section marked with X on the website is that of "The Cache-Control max-age header does not outlive NextUpdate"
When we change the value of the Max-Age header to some lower value, the site ("revocationcheck.com") is showing a general error page with code 520.

Here is the http traffic output for firefox 39 with get:

	GET /ocsp/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR7f2GN0VPh0vethi8ADMbwoRa8sAQU9but6jEjSwBdW0923m%2BLAuD93%2FACEEkFEHGk6GEvlogOQkPelmM%3D HTTP/1.1
	Host: ocsp1.comsign.co.il
	User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:39.0) Gecko/20100101 Firefox/39.0
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
	Accept-Language: en-US,en;q=0.5
	Accept-Encoding: gzip, deflate
	Connection: keep-alive

	HTTP/1.1 200 OK
	Cache-Control: max-age: 43200
	Content-Length: 1681
	Content-Type: application/ocsp-response
	Expires: Thu, 09 Jul 2015 09:00:07 GMT
	Last-Modified: Wed, 08 Jul 2015 09:00:06 GMT
	ETag: "7f72ed853627aeac9f8a11aab6e048dc"
	Server: Microsoft-IIS/8.5
	X-Powered-By: ARR/2.5
	X-Powered-By: ASP.NET
	Date: Wed, 08 Jul 2015 10:51:04 GMT
	Set-Cookie: visid_incap_184418=k9Br4DtOTDiqaAP/v+5psKAAnVUAAAAAQUIPAAAAAABxgE/XV0mPVzskxbnjfJI3; expires=Fri, 07 Jul 2017 07:13:48 GMT; path=/; Domain=.comsign.co.il
	Set-Cookie: incap_ses_227_184418=iNrMJBlaiX2VK6lOKXgmA6AAnVUAAAAAl7nytQBw2MXtZYfsmfZXqg==; path=/; Domain=.comsign.co.il
	Set-Cookie: ___utmvmFVucciI=imONPAMTihv; path=/; Max-Age=900
	Set-Cookie: ___utmvaFVucciI=aEK.pKVw; path=/; Max-Age=900
	Set-Cookie: ___utmvbFVucciI=tZM
		XqUOhalL: otw; path=/; Max-Age=900
	X-Iinfo: 10-12600523-12600526 NNNN CT(11 -1 0) RT(1436352672130 2) q(0 0 0 -1) r(2 2)
	X-CDN: Incapsula
...[OCSP Response]...



And here for Firefox 39 with POST:

	POST /ocsp HTTP/1.1
	Host: ocsp1.comsign.co.il
	User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:39.0) Gecko/20100101 Firefox/39.0
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
	Accept-Language: en-US,en;q=0.5
	Accept-Encoding: gzip, deflate
	Content-Length: 83
	Content-Type: application/ocsp-request
	Connection: keep-alive

	0Q0O0M0K0I0...+........{.a..S...../..............1#K.][Ov.o........I..q..a/...BC..cHTTP/1.1 200 OK
	Cache-Control: max-age: 43200
	Content-Length: 1681
	Content-Type: application/ocsp-response
	Expires: Thu, 09 Jul 2015 09:00:07 GMT
	Last-Modified: Wed, 08 Jul 2015 09:00:06 GMT
	ETag: "7f72ed853627aeac9f8a11aab6e048dc"
	Server: Microsoft-IIS/8.5
	X-Powered-By: ARR/2.5
	X-Powered-By: ASP.NET
	Date: Wed, 08 Jul 2015 11:22:41 GMT
	Set-Cookie: visid_incap_184418=KLyUsQvJSgqc/NnBCgopTggInVUAAAAAQUIPAAAAAADtbigGBc0nyNRFLmRR8NC9; expires=Fri, 07 Jul 2017 07:13:48 GMT; path=/; Domain=.comsign.co.il
	Set-Cookie: incap_ses_227_184418=fN/0FDFBPzolkrROKXgmAwgInVUAAAAAW4XrQdkkzp3o7NLMV3T1Hw==; path=/; Domain=.comsign.co.il
	X-Iinfo: 4-2964612-2964613 NNNN CT(7 -1 0) RT(1436354568688 1) q(0 0 0 -1) r(3 3) U6
	X-CDN: Incapsula
...[OCSP Response]...

Can you please check the OCSP response with some other means (besides revocationcheck.com?
Thanks.

Comment 28

[Kathleen Wilson]

I have the same problem with revocationchecker not working with the test site, with no useable information. I have sent email to the author of the revocationchecker site, but he may be on summer vacation.

So I tested with an old script that I used to use, and I get: Response Verify Failure
2700431852:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate

But I'm not sure why I get that error, as I have also tested in Firefox with OCSP enforced, and it appears to work.

So, I'll proceed with the evaluation of this request, and will update this bug when I get a response from the author of the revocationchecker site.

Comment 29

[Kathleen Wilson]

Attachment: 675060-CAInformation-Complete.pdf

Comment 30

[Kathleen Wilson]

I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 31

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #28)
> I have the same problem with revocationchecker not working with the test
> site, with no useable information. I have sent email to the author of the
> revocationchecker site, but he may be on summer vacation.

The revocationchecker site has been fixed, and https://certificate.revocationcheck.com/fedir.comsign.co.il results in no errors.

Comment 32

[Kathleen Wilson]

Attachment: 675060-CAInformation-Complete.pdf

Comment 33

[Kathleen Wilson]

Attachment: 675060-CAInformation-Complete.pdf

Updated to reflect that Mozilla is no longer enabling the Code Signing trust bit for root certs, because we are planning to remove that trust bit from Mozilla policy.
Reference: https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3

Comment 34

[Kathleen Wilson]

I am now opening the public discussion period for this request from ComSign 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.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "ComSign Root Renewal Request".

Please actively review, respond, and contribute to the discussion.

A representative of ComSign must promptly respond directly in the discussion thread to all questions that are posted.

Comment 35

[Eli Spitzer]

Attachment: Comsign Global WebTrust CA Audit Report 2016

Comment 36

[Eli Spitzer]

Attachment: Comsign Global CA Assertion of Management CA Operations 2016

Comment 37

[Eli Spitzer]

Attachment: Comsign Global WebTrust SSL Audit Report 2016.pdf

Comment 38

[Eli Spitzer]

Attachment: Comsign Global CA Assertion of Managment SSL 2016.pdf

Comment 39

[Kathleen Wilson]

I have exchanged email with the auditor who confirmed the authenticity of the WebTrust CA and WebTrust BR audit statements that have been attached to this bug.

There is one remaining action item before the discussion can continue:
"1) Updated/restructured CPS (both in Hebrew and translated into English)."

Comment 40

[Eli Spitzer]

Attachment: Comsign Roots WebTrust CA Audit Report 2016-Rev_2.pdf

Added a revised "WebTrust for CA" audit statement from our WebTrust auditor, for the same audit period.

Comment 41

[Eli Spitzer]

Attachment: Comsign Global WebTrust SSL Audit Report 2016.pdf

Added a revised "WebTrust for SSL BR" audit statement for "Comsign Global Root CA" from our WebTrust auditor, for the same audit period.

Comment 42

[Kathleen Wilson]

The status of this discussion is that we are waiting for the CA to provide updated/restructured CPS (both in Hebrew and translated into English).

Comment 43

[Eli Spitzer]

Attachment: Comsign Roots WebTrust CA Audit 2017.pdf

Comment 44

[Eli Spitzer]

Attachment: Comsign Global Root WebTrust SSL Audit 2017.pdf

Comment 45

[Kathleen Wilson]

I see that an English version of the updated CPS was published on May 25, 2017.
https://www.comsign.co.uk/?page_id=1282
Presumably, this solves the remaining action item per Comment #39.

However, we have added a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA/BR_Self-Assessment

It includes a link to a template for the CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing


Eli, Please perform the BR Self Assessment and attach the completed document to this bug.

Comment 46

[Eli Spitzer]

(In reply to Kathleen Wilson from comment #45)
> I see that an English version of the updated CPS was published on May 25,
> 2017.
> https://www.comsign.co.uk/?page_id=1282
> Presumably, this solves the remaining action item per Comment #39.
> 
> However, we have added a BR-self-assessment step to Mozilla's root
> inclusion/change process.
> 
> Description of this new step is here:
> https://wiki.mozilla.org/CA/BR_Self-Assessment
> 
> It includes a link to a template for the CA's BR Self Assessment, which is a
> Google Doc:
> https://docs.google.com/spreadsheets/d/
> 1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing
> 
> 
> Eli, Please perform the BR Self Assessment and attach the completed document
> to this bug.

Kathleen, the CPS version that we published on May 25 is not yet the version that should solve that remaining action item. This CPS version only updates some specific details, such as the current Webtrust standard version.
We are in the final stages of a new CPS, which should solve the action item that you mentioned. I hope this CPS would be published within the next few weeks. 
Regarding the BR-self-assessment, we will address that too shortly.

Comment 47

[Eli Spitzer]

Attachment: Comsign Ltd - CA's BR Self Assessment

Comment 48

[Eli Spitzer]

Hello,
We have two updates for this bug:

1. We have completed the CA's BR Self-Assessment. It is attached to this bug.
2. We have created a new version of the CPS. The new version is 4.0 and is available in these links:
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS-EN-v4.0.pdf
https://www.comsign.co.uk/?page_id=1282
https://www.comsign.co.il/repository/
https://www.comsign.co.il/cps

Hopefully we could now continue the discussion of the new root inclusion.

Thanks,
Eli Spitzer | Information security & System Management | Comda - Comsign

Comment 49

[Aaron Wu]

Hi Eli,

Thank you to provide BR Self Assessment and updated CPS.

According to Test websites in BR Self Assessment you provided, it seems valid website doesn't chain up to root cert. Could you please double check?

Thanks,
Aaron

Comment 50

[Eli Spitzer]

(In reply to Aaron Wu from comment #49)
> Hi Eli,
> 
> Thank you to provide BR Self Assessment and updated CPS.
> 
> According to Test websites in BR Self Assessment you provided, it seems
> valid website doesn't chain up to root cert. Could you please double check?
> 
> Thanks,
> Aaron

Hi Aaron,
You are right about the test website's certificate chain. There was some issue with the WAF on that specific website. It should be fine now.
Regards,
Eli

Comment 51

[Aaron Wu]

Hi Eli,

Thanks to solve the issue on test website as I mentioned in Comment#49.

We are do the final verification of your updated CPS, please stay tuned.

Thank you so much!


Kind regards,
Aaron

Comment 52

[Aaron Wu]

Hi,

I've verified CPS v4.0 and BR Self Assessment, and also make update in CCADB accordingly.

We will restart the discussion of this request soon, thank you!

Best Regards,
Aaron

Comment 53

[YairE]

Hi Aaron,
Im speaking in behalf of Eli Spitzer.
 I just wanted to ask if you have an estimated time limit to when will we be back on the public discussion.
Thank you

Kind Regards.
Yair.

Comment 54

[Aaron Wu]

Hi Yair,

We are verifying and consolidating the information to make all the things ready back to discussion, once done I will post it on m.d.s.policy forum. Thank you!


Kind Regards,
Aaron

Comment 55

[Kathleen Wilson]

The discussion about this request has been re-started:

https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/YlkF0HdEAgAJ

Comment 56

[YairE]

(In reply to Kathleen Wilson from comment #55)
> The discussion about this request has been re-started:
> 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/
> YlkF0HdEAgAJ

 Hi Kathleen and Aaron
I tried to respond to the discussion on https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/YlkF0HdEAgAJ
but my reply was held because im not a member of the group - how can i sign to the group?

thank you.

Comment 57

[Wayne Thayer]

(In reply to YairE from comment #56)
> I tried to respond to the discussion on
> https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/
> YlkF0HdEAgAJ
> but my reply was held because im not a member of the group - how can i sign
> to the group?

If you subscribe to the mailing list using the same email address as your Google account, I think you'll be able to post via Google Groups. You can subscribe here: https://lists.mozilla.org/listinfo/dev-security-policy

Comment 58

[YairE]

Hi Wayne,
as recommended i'm adding here the file of the certificates issued since 26/10/2014 until 31/03/2015 

https://drive.google.com/file/d/1GpF1s6WiFb5yywmqwh3JAW0I7RxQNTyJ/view?usp=sharing

Comment 59

[YairE]

Attachment: Cert list

Comment 60

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 61

[Wayne Thayer]

Mozilla is denying the ComSign Global Root CA inclusion request due to concerns raised during the public discussion at https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/Ck5Z8JS7AQAJ

ComSign may submit a newly generated root and key-pair for inclusion.

Moving this bug to on-hold pending submission of the new root.