Thanks for the request. The template automatically labelled this "Enterprise", which is most definitely not the right group to tackle this. I'm honestly unclear what the right labels would be and whether this bug tracker is the correct one for this request, but I'll mark it security for now and CC a few people that can certainly help with routing.

I'm not sure this request meets the bar for "operating in the public interest" (as similarly expressed in https://bugs.chromium.org/p/chromium/issues/detail?id=698094#c7 ), and would want to have a discussion on ct-policy@ before accepting this log for Chromium.

I'm also not sure the Log's policies, as stated, are that clear. That is, 
"The CT Log Server is implemented and operated by SHECA. Any person or organization is able to submit a certificate to a log on the server after being tested and approved by SHECA. Besides, SHECA also submits certificate to log on the CT Server of GDCA. SHECA conforms to the clarifications in CP/CPS published on the website of SHECA(http://www.sheca.com/policy), which includes conformance to the latest version of Guidelines and Baseline Requirment on CA/Browser Forum and the related laws and regulations published by Government and Official Departments in charge. "

1) "Any person or organization is able to submit a certificate to a log on the server after being tested and approved by SHECA"
 - Does this mean you will add any Root CA certificate that requests?
 - What does testing constitute?
 - What does approved constitute?
2) "Besides, SHECA also submits certificate to log on the CT Server of GDCA."
 - This sounds like you're discussing logging of the certificates SHECA issues, rather than what you do with certificates logged to the SHECA CT Log. Is this correct?
3) "SHECA conforms to the clarifications in CP/CPS published on the website of SHECA(http://www.sheca.com/policy), which includes conformance to the latest version of Guidelines and Baseline Requirment on CA/Browser Forum and the related laws and regulations published by Government and Official Departments in charge."
  - This is clearly describing the CA's operation, not the Log's operation.


By comparison, https://bugs.chromium.org/p/chromium/issues/detail?id=703699 represents a greater level of detail both about how the log operates and how it determines what CAs to trust.

As we continue to refine our ct-policy@, it's very likely that this log would be rejected or subsequently removed with the current set of root certificates and policies. That's why I want to try to better understand and see how we can help :)

The certificate used for the HTTPS service appears to chain to a root that is not trusted on my platform, as well? Which root program has that root been accepted in?

Assigning to Ryan, until the Chromium policy requirements are fulfilled, please re-assign back to me once this is ready to have the compliance monitoring period started?

I'm having 2 issues with this:
- It's not sending a full chain, there is only a certificate for ct.shaca.com itself not the intermediate nor the root CA.
- DNS returns NXDOMAIN some of the time. Of course the resolver keeps a negative cache (of 3 hours), turning this into a large time that I'm not able to connect.

From the few STHs I was actually able to retrieve, I received an STH that was 1.2 seconds in the future.

Still hoping for answers in Comment #3

The clock still seems to be drifting, it's currently at 7.2 seconds in the future.

I'm also concerned that it still only have 2 entries.

Hi, Ryan. Thank you for your comments. I feel very sorry that I may not present the description of the log very precisely. Here let me explain it more specific.
1) "Any person or organization is able to submit a certificate to a log on the server after being tested and approved by SHECA"
 - Does this mean you will add any Root CA certificate that requests? 

Ruby:
No. This log has specific policy for accepting root certificates, only those in line with the log policy will be accepted. As for the log policy, please see the following “Root acceptance policy” part.

- What does testing constitute?
 - What does approved constitute?
Ruby:
When I mentioned”tested and approved by SHECA” in my previous presentation, I mean we do have a procedure determining root inclusion. As for the detailed procedure, please refer to the Log’s policy below.

2) "Besides, SHECA also submits certificate to log on the CT Server of GDCA."
 - This sounds like you're discussing logging of the certificates SHECA issues, rather than what you do with certificates logged to the SHECA CT Log. Is this correct?
Ruby:
Sorry here I made a mistake. And yes, it has nothing to do with SHECA’s log policy. I was just trying to tell more by demonstrating that we will submit our certificates to the log of GDCA.
 
3) "SHECA conforms to the clarifications in CP/CPS published on the website of SHECA(http://www.sheca.com/policy), which includes conformance to the latest version of Guidelines and Baseline Requirment on CA/Browser Forum and the related laws and regulations published by Government and Official Departments in charge."
  - This is clearly describing the CA's operation, not the Log's operation.
Ruby:
Thank you for pointing this out. It lets us think more about what policy is good for this log’s operation. Here is the detail policy about this log.

-	Root acceptance policy: 
This log accepts roots that meet all the following requirements,
1 The Root CA passes the WebTrust Audit and the root certificate is included in the audit report.
2 Root certificates that are included in at least two of the Google, Microsoft, Mozilla and Apple root programs.
3 The root certificate has never been recorded or discussed on CAB Forum because of operation against the BRs or guidelines. 
Besides, we will update this log's list of accepted roots from time to time in accordance with this policy.
-	Free:
SHECA doesn’t charge any fees for accepting a root certificate. There is also no cost for submitting certificates/precertificates to this log. But SHECA reserves the right to charge for the service in the future if needed. 
-	Agreement
Before the acceptance of the root certificate, the root CA need to sign an agreement with SHECA by making a statement that it will follow SHECA’s log policy and inform SHECA in time when any violation of this log’s policy happens.
-	Rate limits: 
Submissions are rate-limited by IP address. SHECA reserves the right to set rate limitation according to its spare capacity in the future.
-	Reasonable Commercial Efforts: 
After the agreement is signed by the root CA and SHECA, all submissions of certificates issued under that root certificate are supposed to be allowed. But SHECA reserves the right to remove  (temporarily or permanently) any root from this log's list of accepted roots, with a prior notice according to the agreement,if SHECA is unable to cope with the rate of submissions associated with that root.
-	Update： 
SHECA reserves the right to update this log policy from time to time. The update of this log policy will be performed according to related rules such as the requirements of CAB Forum and Google’s CT program, or SHECA’s CT log operation needs.
-	Disclaimer: 
The log is an aggregate of information from SHECA and third parties not under SHECA's control. Therefore, SHECA does not guarantee accuracy of information from third party sources or contributors. Though SHECA asks for statement of reliable and correct information from the root CA in the agreement, SHECA itself will not guarantee for information reliability and accuracy. Further, SHECA does not guarantee the performance or availability to any end users of the log, whether to certification authorities or other submitters or to any parties or individuals who want to read the status or the content of this log. 

Removing Needs-Feedback based on c#13.

I am sorry for the late response. 
To pphaneuf@google.com :
The certificate issued by SHECA used for the HTTPS service chains to a root(UCA Global G2 Root) that has been accepted in Microsoft's Root Program. And we are working on the progress of Mozilla and Apple's Root Program to be trusted by them.
To kurt@roeckx.be :
Thanks for your comments. We have added the intermediate certificate. As for the technical issues, it probably is because of the network operator policy of China and we are now working on these issues.

The clock is now off by at least 47 seconds.

Apologies, I sadly missed Comment #13:

With respect to the log policy, I'm not sure that the accepted root policy works towards the public interest. For example, SHECA's own CA has violated the BRs in the past (https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/771PAebFAQAJ / https://crt.sh/?id=12367776&opt=cablint ). It's also worth noting that the CA/Browser Forum does not discuss CAs BR-non-compliance, but Forum members do.

It also suggests that SHECA will not consider ETSI audits as acceptable either. Hoping you can explain that.

For comparison, it might be useful to compare with https://bugs.chromium.org/p/chromium/issues/detail?id=768309 or the discussion there on what might be sufficiently robust policies.

xiongyuanyuan@, can you respond to comment #17?

xiongyuanyuan@.  friendly ping, please respond to comment #17.  otherwise, we'll have to archive this issue.

Closing as WontFix due to lack of response to Comment 17.