Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 667663 Certificate Transparency - PuChuangSida CT Log server inclusion.
Starred by 2 users Reported by, Nov 22 Back to list
Status: Started
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 3
Type: Feature

Sign in to add a comment
Steps to reproduce the problem:
Log Server URL:
MMD: 24 hours
HTTPS supported: yes 
Operator: Beijing PuChuangSiDa Technology Ltd.
- email:
- Phone: +86 17316230527
- contact persons: PCSD IT Operation

Log Server Public Key:
-----END PUBLIC KEY-----

A description of the Log:
The Compliance Monitoring Root is added to the CT Log. 

Accepted Roots: 

What is the expected behavior? 

What went wrong?
PuChuangSiDa CT Log server apply for inclusion in Chrome.

Did this work before? 
2.0 KB Download
Components: Internals>Network>SSL
Components: -Internals>Network>SSL Internals>Network>CertTrans
Labels: -Type-Bug Type-Feature
Status: Started
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 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 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:!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.
Status: ExternalDependency
I attached the revised sets of roots accepted by PuChuangSida CT Log, PCSD_ct_trust_root_certs.pem , please check the attachment.

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.
Comment 11 Deleted
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.

Status: Started
Would you like to name your log, or shall I simply dub it "PuChuangSiDa 1"?
 Thanks. Please use name: PuChuangSiDa CT Log 1.

NextAction: 2017-03-20
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.
Comment 16 by, Mar 20 (6 days ago)
NextAction: ----
This log has passed the initial 90 day compliance period and we will start the process to add this to Chrome.
Project Member Comment 17 by, Mar 22 (4 days ago)
The following revision refers to this bug:

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

Add PuChuangSiDa CT log to known logs list

They have completed their initial compliance monitoring.


Cr-Commit-Position: refs/heads/master@{#458762}


Comment 18 by, Mar 22 (4 days ago)
Rob: Are you going to do the Merge & Merge-Request to M58?
Comment 19 by, Mar 22 (4 days ago)
Labels: Merge-Request-58
I'll do the merge request, but eranm@ will handle the actual merge as I do not have commit rights.
Comment 20 by, Mar 22 (4 days ago)
Labels: M-59 OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Wiki updated to reflect 59. When this lands to 58, let's update the Milestone and Wiki to reflect this.
Project Member Comment 21 by, Mar 22 (4 days ago)
Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
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 - Your friendly Sheriffbot
Comment 22 by, Mar 22 (4 days ago)
Sign in to add a comment