Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 667663 Certificate Transparency - PuChuangSida CT Log server inclusion.
Starred by 2 users Reported by, Nov 22 Back to list
Status: Started
NextAction: 2017-03-20
OS: ----
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.
Sign in to add a comment