First, thanks for Rob's help.
Yes, this is our promise to WoSign worldwide customers for transparency since we know some west subscribers have prejudice to China CA.

Second, WoSign is volunteering to “require CT” for all browsers, this is different from  Issue #620178  that Google require Symantec to be Required CT. 
And I wish Comodo and other leading CA can be volunteering to have their roots added to the "require CT" list, and I believe that all SSL certificate will be CT support in the future that it will become baseline requirement.

Third, WoSign is developing OCSP CT support solution, this will help other CAs that no need to update the PKI/CA system, but support CT for all issued SSL certificate. I think the best solution is not the OCSP Stapling CT support, the best solution is the SCT data included in the OCSP response that browser can get the SCT data from the response to confirm the certificate is CT-enabled, no need to communicate with web server to get SCT data from stapling since many website still don’t support OCSP stapling. I don’t know if Chrome support this mode, please advise, thanks.

If the question is whether Chrome fetches OCSP responses from the CA's OCSP responder directly, then I believe the answer is no. During the certificate validation process (where compliance with CT requirement is checked) Chrome only takes into account the stapled OCSP response.

So the way for all of WoSign's certificates to be "CT compliant" is to have the SCTs embedded in them, or make sure website owners serve stapled OCSP responses (which, as you pointed out, many websites still don't support OCSP stapling).

Chrome does not support that method, nor will it, nor is delivering SCTs in (unstapled) OCSP messages consistent with RFC 6962, as clearly documented at https://tools.ietf.org/html/rfc6962#section-3.3

Thanks. As we stated all SSL cert issued by WoSign is SCT embedded.
My suggestion is for other CA that no need to change system to support CT, this is easy to promote CT to all CA.

I think it is better to support both mode: (1) browser get the SCT data from web server OCSP stapling; (2) browser get SCT data from CA OCSP response. Then it is easy for CA to support CT, and easy to promote CT, then better to Internet security. 
Maybe we need to update IETF to support both, I think.

This has already been discussed and documented extensively as to why it's an unreasonable and impractical solution. I would encourage you to see the feedback on the IETF's TRANS mailing list for that discussion, but the TL;DR: is that it sets an unacceptable latency with an unacceptably high failure rate (double-digits for some populations).

If you think it's unfair that CT favors reducing latency, please also consider that the design of CT was changed to accomodate CAs' concerns about latency. The original designs would have prevented a CA from issuing the cert until they obtained a full proof of logging (that is, you could not issue a cert until the log had quiesced, which typically means "by the MMD")

Thanks, Ryan. Clearly now. The problem is CA can issue certificate before logging.

I mean my suggestion's problem. So forget my suggestion. But WoSign don't have this problem that all SCT embedded.

Addressed via https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html