Thank you for requesting monitoring. We have reviewed your request and we
will need more information before we can begin monitoring.

Could you please provide the root certificates you intend to trust?

The certificate chain for https://certificatetransparency.cn is incomplete, containing only the end-entity certificate.  Could you configure your server to serve a complete chain?

Thanks for your prompt response. 

During the testing and inclusion period, we are only including Google's monitoring root. After that, we plan to accept all publicly trusted root. We will develop our internal policies to evaluating every root inclusion request. Such policies may include requirement for algorithms, minimum keysize,and similar checks. We may also evaluate the network balance load and scale before we accept a Root certificate.

The certificate of https://www.certificatetransparency.cn is configured with a complete chain.

I'm going to encourage some discussion as to whether the policy should allow a log to go through compliance monitoring with no roots (bar the Google monitoring root), as there has been criticism of this in the past. If you'd like to contribute your reasons for why you think this should be allowed, the forum thread is: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/K_QawRkK0Gw

Thanks for bringing this up, Rob.

Yes, as mentioned in the past, this is not something we want to encourage. I explained more on the list, but this is similar in response to requests for logs from Google and Akamai - that we'd hope to see a clearer policy and inclusion to make sure this is useful and valuable to Chromium users and the ecosystem.

I attached the revised sets of roots accepted by PuChuangSida CT Log, PCSD_ct_trust_root_certs.pem , please check the attachment.

Deleted: PCSD_ct_trust_root_certs.pem 7.0 KB

PCSD_ct_trust_root_certs.pem 7.0 KB Download

Thanks. Can you clarify further a bit on your policies about accepting all publicly trusted roots, but still developing internal policies? Do you have a timeline or plan for accepting additional roots?

I ask mostly because you indeed recognized a potential concern (the network balance load and scale before accepting a root), but also indicated plans to accept all publicly trusted roots, and was hoping for more clarity on those policies, so that they can be weighed against the broader Chromium interest.

However, I don't want that decision to block compliance monitoring, so I think it's useful to begin, but I hope we'll see a bit more detail/plan before making the decision to include (assuming it passes the compliance monitoring phase), since the point of the compliance monitoring is partly to ensure the log can/does meet its uptime/load goals for the roots it trusts.

Thanks. Although we don't have very detailed policy now, we may share some plans and policies as follows,

1, We plan to accept additional root at second half of 2017, it is still TBD as our CT log server need pass Google's compliance monitoring and be included in Chrome successfully. 

2, The root certificate in our log server should be included at least one major browsers or operate system.(IE, Chrome, Firefox,Safari or Windows, MacOS and iOS, Android ).
 
3, The signature algorithm of root certificate must be ECC or RSA (key size is 2048bit at least).

4, The request CA need provide a estimate number of certificate they submit into our log server so that we can extend our network scales in AWS before we accept the root. 
  
5,  We will update in Chromium once(or before) we add a new root into our log server. 

6, PuChuangSiDa reserve the right to reject a root inclusion request for any reason. We also may remove the existing root in our log server in case the CA cease operation or it's not publicly trusted any more due to key compromise and similar incident.

Would you like to name your log, or shall I simply dub it "PuChuangSiDa 1"?

 Thanks. Please use name: PuChuangSiDa CT Log 1.

Thank you for your request, we have started monitoring your log server. Should no issues be detected, the initial compliance monitoring phase will be complete on 20th March 2017 and we will update this bug shortly after that date to confirm.

This log has passed the initial 90 day compliance period and we will start the process to add this to Chrome.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/588960fc36ee4335083ae671f7109b5b5f1d4d08

commit 588960fc36ee4335083ae671f7109b5b5f1d4d08
Author: robpercival <robpercival@chromium.org>
Date: Wed Mar 22 15:47:28 2017

Add PuChuangSiDa CT log to known logs list

They have completed their initial compliance monitoring.

BUG= 667663 

Review-Url: https://codereview.chromium.org/2759293002
Cr-Commit-Position: refs/heads/master@{#458762}

[modify] https://crrev.com/588960fc36ee4335083ae671f7109b5b5f1d4d08/net/cert/ct_known_logs_static-inc.h

Rob: Are you going to do the Merge & Merge-Request to M58?

I'll do the merge request, but eranm@ will handle the actual merge as I do not have commit rights.

Wiki updated to reflect 59. When this lands to 58, let's update the Milestone and Wiki to reflect this.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your change is approved for M58. Please ensure that fix works in canary. If all looks good, merge ASAP so that it will be picked up for next Beta Release, RC cut on (Tuesday-03/28) at 4.00 PM PST.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/98fdca7ac875f8e55a80f8971094411d566cf8eb

commit 98fdca7ac875f8e55a80f8971094411d566cf8eb
Author: Eran Messeri <eranm@google.com>
Date: Mon Mar 27 21:14:24 2017

Add PuChuangSiDa CT log to known logs list

They have completed their initial compliance monitoring.

BUG= 667663 

Review-Url: https://codereview.chromium.org/2759293002
Cr-Commit-Position: refs/heads/master@{#458762}
(cherry picked from commit 588960fc36ee4335083ae671f7109b5b5f1d4d08)

Review-Url: https://codereview.chromium.org/2772413002 .
Cr-Commit-Position: refs/branch-heads/3029@{#442}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/98fdca7ac875f8e55a80f8971094411d566cf8eb/net/cert/ct_known_logs_static-inc.h

I've updated https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency and the milestone, and will now close this issue out.

Please use this issue to report any changes in the set of information collected during this process, consistent with https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency/log-policy

I just reported the following to certificatetransparency@outlook.com:

Hi,

I have been unable to contact the PuChuangSida CT Log since 2017-05-12
02:45 UTC. The connection to port 443 on 35.163.86.183 times out.

Other monitors have also been unable to contact your log over the last
14 hours:

https://ct.grahamedgecombe.com/logs/28

https://crt.sh/monitored-logs

When do you expect this problem to be resolved?

Regards,
Andrew

The server is down due to network issue of AWS. And we also failed to
connect to ec2 server in China.

We are contacting support team of AWS to solve this issue.
We will update the status as soon as we fix it.

regards,

PCSD CT

2017-05-13 1:05 GMT+08:00 agwa-b… via monorail <
monorail+v2.2468521488@chromium.org>:

This log has fallen well below the availability requirements required by the Chromium CT log policy. The last STH Google's compliance monitoring system was able to obtain was the following, with a timestamp of 2017-05-11 02:50:17 UTC:

{"tree_size":1730,"timestamp":1494471017880,"sha256_root_hash":"flv/BoL1p/esSEwmeAc7b0pDFDJ3SDJm+45vpcCTyG4=","tree_head_signature":"BAEBAJIuIJPLGlBCnjljchrHI5lNkWB/M8D3AeQ52InFfY4kqEb1XxXvXemBs6+82oEO8KMBYerd2B+W4DL6wg4PrmqMfAANldz9RASfdrmFBNFQGGaCRcUx9OlpwsT6A7deiFdoJF7nBKXz/d4gmrET75k0dE72EHl/xTI2kooBWe1lXb2WjAfr67JqGUUozceVaJ8Hk9FUN3YlGzk22FDqv36xY9ghKI6p2vL3sOeqnnR5SEsU6ndV4odit6HW5X5qkNL61Pih/E35ksrnyWFQeg10FpBT4IGREGOC9lUArmGxMx/ENG422+fME0bytnI1aHHfDO9BmVBqufSNbUDRM7Q="}

The latest timestamp I saw was from 2017-05-12 02:40:17.880 UTC, which seems to match the other monitors. I'm not sure you talk about almost a day earlier, it worked fine that day. It stopped replying since the 12th.

Thanks for pointing that out, the system I took that STH from didn't have the latest STHs; I suspect because the log was not up to provide consistency proofs when it got around to verifying them. I've checked our record of unverified STHs and can see an STH from 2017-05-12 02:30:17.880 UTC:

{"tree_size":1745,"timestamp":1494556217880,"sha256_root_hash":"hmBP+e06nqHWMLEfGaQmx9jNuidJ01Vuu/rOZNYC2i4=","tree_head_signature":"BAEBAIKxjF+VQdKQdl/tnrnLfnVQaiYf8g/6Tg5oFpcKZGox5uruYrE+RNQGv5VKIGrpCp3OYg0iDN6dFXD5NqAeWPmjTCWNMNgjMQV+FX5Z6EaPQCvAzIDyUUmJYykcxuvfN6zBVbg0nM5ZSxLeAy0+PychVxeYVHYRgyu4zjk5taIFrZyUERvWaaohsksyzjUDfP7IuCFAvzICvXXCX65ZO1eouERVXbYveCmX/IYPDv9Tlc8KWMBPk35OHahgoErEMQHeJrrU64B9k/2S2G8i0lZEG54kLaP7P5idmy51Ci/NFTagNdFvOnTC8bH2lwtzAlh1Wj6q9ZVpBUCYuZVME84="}

Nonetheless, the log is well below the availability requirements.

FYI, the bug that tracked removing this log was  http://crbug.com/731836 .