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 598526 Certificate Transparency - GDCA CT Log Server Inclusion
Starred by 3 users Reported by hanjie77...@gmail.com, Mar 29 2016 Back to list
Status: WontFix
Owner:
User never visited
Closed: Oct 21
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Feature


Sign in to add a comment
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
Log Server URL: https://ct.gdca.com.cn/ct/v1
HTTPS supported: yes
MMD: 24 hours

Contact Information:
- email: capoc@gdca.com.cn;
- phone number:  +86(20)83487228-805
- Log Operator: Wang Shengnan

Server public key: Attached file: gdca-ct-key-public.pem
Accepted Roots: Attached file: gdca-trusted-roots.pem

the "Merge Delay Monitor Root" already add in the trusted roots file.

Log Description and Policy: Currently, the only policy in place is that the certificate chain to a publicly trusted root certificate.  However, during the testing and log inclusion process, we are only including the GDCA trusted roots as authorized. Additional root entries will be evaluated after receiving an inclusion request. We will likely develop our policies further based on the results from the discussions in the Trans working group and our own internal policies.  Such policies may include an enforcement of BR and EV standards, a requirement for at least organizational vetting on the certificate, minimum key sizes and hash algorithms, and similar checks.

What is the expected behavior?

What went wrong?
The GDCA CT Log Server is ready to be included in the Chrome and Chromium browsers.

Did this work before? N/A 

Chrome version: 49.0.2623.87  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0
 
gdca-ct-key-public.pem
178 bytes Download
gdca-trusted-roots.pem
3.0 KB Download
Cc: rsleevi@chromium.org
Components: Internals>Network>SSL Internals>Network>CertTrans
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Status: Untriaged
(Moving to Untriaged as per net triage instructions to get it off triager's radar screens.)

Comment 3 by eranm@chromium.org, Mar 29 2016
Owner: eranm@chromium.org
(assigning to myself for so it's not lost)
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 July 6 2016 and we will update this bug shortly after that date to confirm.
gdca-trusted-roots.pem
4.0 KB Download
Update the file to the same as the one on the log server. Thank you!
Issue 594441 has been merged into this issue.
Status: Assigned
Unfortunately, it appears that the log server did not have sufficient availability, having 98.756% of reachability probes successful (with the policy requiring at least 99%, which allows for 21 hours and 36 minutes of unavailability in the 90 days monitoring period).

To re-apply, you would need to clear the log and change the keys (in essence, a new log).
Hello, I have some doubts.
First of all, We monitor our log every minutes and the log have 99.50% uptime. Our log also have 99.41% uptime from other CT monitor(https://ct.grahamedgecombe.com/). 
Can you tell us how the percent of availability is calculated?
We will check our log and clear the log. Then we plan to re-apply later. Can we re-apply in this issue or create a new one ?
You should re-apply in a new issue.
You should also change the log key, so it's effectively a new log.
I recommend a new URL for the new log - it does not have to be a new domain, so you could use https://ct.gdca.com.cn/new_log/ct/v1 or something similar.

Please CC me directly on the new inclusion request so we don't have to wait for it to be triaged. 
OK.Thank you.
Cc: eranm@chromium.org
Owner: pphaneuf@google.com
The frequency of our monitoring is variable, averaging about every two minutes. The availability is calculated as a ratio of successful probes over the total number of probes.

It is possible that a similar amount of unavailability could result in a lower percentage with a lower frequency. For example, your monitoring is done every minute, and had 0.5% of unavailability, the same number of failed probes with a 2 minute frequency would result in 1% of unavailability. In an extreme case, if we did a single probe per day, only one of them failing would immediately bring the availability below 99%!

We are looking into ways to improve our compliance monitoring system at the moment, but for now, we are applying the same methodology to every logs.
Comment 16 Deleted
We had re-applied in a new issue. here is the link to the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=654306
Labels: -OS-Windows -Type-Bug Type-Feature
Status: WontFix
Sign in to add a comment