Log lists outdated and inconsistent

[Hanno Böck]

Hi,

I have complained about this before, but it seems the situation hasn't
improved.
I'm quite uphappy with the state how the information about logs is
provided. I think this information should be provided in an easily
consumable way for everyone trying to build tools and services around
CT.

I want a relatively simple thing: I simply want a list of all CT logs
that are currently available and can be queried. Yet the current data
doesn't give me that list.

The problems:

1. data out of sync
===================

The webpage
https://www.certificate-transparency.org/known-logs
and the
https://www.gstatic.com/ct/log_list/all_logs_list.json
aren't in sync.

The json contains the following logs that are not on the webpage:
clicky.ct.letsencrypt.org/
ct.akamai.com/
ct.filippo.io/behindthesofa/
ct.googleapis.com/daedalus/
ct.googleapis.com/submariner/
ct.googleapis.com/testtube/
ctlog2.wosign.com/
ctlog.sheca.com/
ct.sheca.com/
deneb.ws.symantec.com/
dodo.ct.comodo.com/
flimsy.ct.nordu.net:8080/
plausible.ct.nordu.net/

2. unclear from json which logs are operational
===============================================

If I'm not missing something the all_logs_list.json doesn't seem to
contain any information whether the log is still operational.
The webpage lists old logs under "Logs that ceased operation". It would
be valuable to have that information in the json as well.

3. Unavailable logs
===================

The following logs don't answer:
clicky.ct.letsencrypt.org/
ct.akamai.com/
ct.gdca.com.cn/
ct.izenpe.eus/
ctlog.gdca.com.cn/
ctlog.sheca.com/
ct.sheca.com/
flimsy.ct.nordu.net:8080/

Yet they are not listed on the webapge under "Logs that ceased
operation".


Ideally I'd ask for the following things:
* The webpage and the machine readable data in json format should be
consistent. Ideally it should probably be maintained in json and the
webapge should automatically be created and updated based on that
data.
* The machine readable data should contain the information whether a
log is still operational or not.
* This should be monitored and logs that are permanently offline should
be marked as such.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Kat Joyce]

Hi Hanno,

We are aware that all_logs_list.json and the Log information are not currently in sync, and we do plan to do the work to auto-generate the information displayed from the JSON log lists.  We considered removing the Log information that is displayed completely until this work is done, but chose not to as there is extra information about some Logs there than is not currently in the JSON files, for example links to the chrome inclusion request bugs.  However, if the inconsistency is problematic, we are happy to remove the out of date displayed Log data until we are able to do the work to auto-generate it.

We also have work in the pipeline to expand the JSON schema for the uploaded Log lists to include more metadata about each Log, for example it's Chrome inclusion statues, bug etc.  This schema expansion will remove the need for two separate JSON log lists.  However, this work is unlikely to be completed this quarter, but know that it is coming!

With regards to displaying which Logs are 'operational', unfortunately we have no plans to include this information in the JSON Log lists, but with reason.  There is no way to know for sure which Logs have permanently ceased operation.  For Logs that currently appear to be off there is no reason that they could be switched on again by their operators at any time.  There are only requirements on the behaviour of Logs included in Chrome (which are listed in log_list.json) - other Logs are free to do what they wish, including being available as and when they like.  In the same way, there is nothing to stop a currently operational Log switch off at any time.  So this information will not be present even in the updated schema that we plan to develop, as there is simply no way to be certain when making this judgement.

Kat

--

You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Percival]

Thanks for highlighting those inconsistencies. I've added ctlog2.wosign.com to the webpage, which recently begun compliance monitoring for inclusion in Chrome. The Google logs you mentioned were already on the webpage though, under the "Special Purpose Logs" section. I believe the rest of the logs you mentioned are either experimental or defunct (please point out any exceptions), so we've not added those.

[the...@googlemail.com]

...forgot to link the script: https://github.com/theno/ctutlz#ctloglist

[the...@googlemail.com]

Hi,

I just wrote a script which sums up the infos of all three log lists (log_list.json, all_logs.json and webpage). It not only lists the logs listed in all_logs.json which are missing at the webpage as pointed out by Hanno, but also finds some oversights:

```
>  .tox/py36/bin/ctloglist 1>/dev/null
inconsistent data for log sirius.ws.symantec.com/: FZcEiNe5l6Bb61JRKt7o0ui0oxZSZBIan6v71fha2T8= != ZcEiNe5l6Bb61JRKt7o0ui0oxZSZBIan6v71fha2T8=
inconsistent data for log ctlog.wosign.com/: ['Wosign'] != ['WoSign']
inconsistent data for log ct.startssl.com/: ['StartSSL'] != ['StartCom']
inconsistent data for log ctlog2.wosign.com/: ['Wosign'] != ['WoSign']
inconsistent data for log ct.wosign.com/: ['Wosign'] != ['WoSign']
log in all_logs.json not listed on webpage: deneb.ws.symantec.com/
log in all_logs.json not listed on webpage: dodo.ct.comodo.com/
log in all_logs.json not listed on webpage: flimsy.ct.nordu.net:8080/
log in all_logs.json not listed on webpage: plausible.ct.nordu.net/
log in all_logs.json not listed on webpage: ctlog.sheca.com/
log in all_logs.json not listed on webpage: ct.sheca.com/
log in all_logs.json not listed on webpage: ct.akamai.com/
log in all_logs.json not listed on webpage: clicky.ct.letsencrypt.org/
log in all_logs.json not listed on webpage: ct.filippo.io/behindthesofa/
```

Am Dienstag, 18. Juli 2017 12:18:08 UTC+2 schrieb Rob Percival:

[Alan Parra]

Hi,

Thanks for your feedback. I've fixed sirius' Log ID and the WoSign / StartCom inconsistencies. Gstatic changes take some time to propagate, but they should go live soon.

Meanwhile, we're looking at automatically generating the page text from the lists, so that we won't have those inconsistencies again. Because of that I won't be adding the non listed logs now.

Kind regards.

[Morgan Taylor]

None of the links seem to be working for me, including the ones you mentioned that were recently fixed. Or are the logs not accessible by browser or curl? If the links to the logs are all functional, then I'm seriously missing something about how to access/view/search them. Where are instructions about that posted?

[Kat Joyce]

Hi Morgan,

The Logs are accessible by both browser and curl, but you have to correctly query the API endpoints described in section 4 of RFC 6962.  You make a good point that this is not immediately obvious from the known logs page itself - we will remedy that.

For example, to get the latest STH from the Google Pilot Log, try either:

- running "curl https://ct.googleapis.com/pilot/ct/v1/get-sth"

- going to https://ct.googleapis.com/pilot/ct/v1/get-sth in your browser

If you have any further questions about how to query Logs, or do something specific, please don't hesitate to ask!

Kat

--

[Morgan Taylor]

Thank you!!

[the...@googlemail.com]

Hi Alan, and all others,

I just updated the script [ctloglist](https://github.com/theno/ctutlz#ctloglist) to be able to parse the changed Listing in https://www.certificate-transparency.org/known-logs (from 2017-08-24).

It now shows three logs which are in the *.json files but not listed on the webpage:

> .tox/py27/bin/ctloglist 1>/dev/null

log in log_list.json not listet on webpage: log.certly.io/

log in log_list.json not listet on webpage: ct.izenpe.com/

log in log_list.json not listet on webpage: ctlog.api.venafi.com/

log in all_logs.json not listed on webpage: log.certly.io/

log in all_logs.json not listed on webpage: ct.izenpe.com/

log in all_logs.json not listed on webpage: ctlog.api.venafi.com/

This three logs have been disqualified according to chromes ct-policy: https://github.com/GoogleChrome/ct-policy

What are the states according to the chrome ct-policy?

And how are the possible transitions?

What is the difference between a 'rejected' and a 'distrusted' log?

The states that I could "reverse-engineer": https://github.com/theno/ctutlz/blob/master/ctutlz/ctlog.py#L21

Theodor Nolte

[Kat Joyce]

Theodor,

The Logs you mention as missing from the page are not.  The are listed under 'Disqualified from Chrome'.  If your script is reporting that they are missing then it is an error on your end, not ours.

The Chrome CT Policy itself does not define official states.  We do plan to externally define official states that a Log can be in in the future as part of the work to expand the current JSON schema (see my previous message in this thread), but, as I mentioned, that is future work that is unlikely to be done soon.  For now the headings displayed on that page are meant simply as an indication of what has happened to the Log wrt inclusion in Chrome, and may change in the future.

Wrt the two headings you specifically ask about, Logs that have been rejected by Chrome were exactly that - rejected for inclusion in Chrome, so never made it in to Chrome as a trusted Log.  Logs that have been distrusted by Chrome were previously trusted, and were then completely removed from Chrome's list of trusted Logs.

Kat

--

You received this message because you are subscribed to the Google Groups "certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscr...@googlegroups.com.

[the...@googlemail.com]

Kat,

indeed, that was an error in the script, it's fixed now. Sorry for any circumstances. Now, there is a warning for any unknown log-heading in the script `ctloglist`. So I would (hopefully) not make this mistake again.

Thank you for your explanations of the log headings.

Maybe it would be a good idea if the JSON schema would contain 'description' fields, which explain or describe the log states. Like it already exists for the 'dns_api_endpoint'.

Btw, I could not find any explanation on https://certificate-transparency.org about the meaning of 'dns_api_endpoint' entries, and what it is good for.

(dns_api_endpoint infos: https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md)

Theodor

Am Donnerstag, 31. August 2017 13:05:06 UTC+2 schrieb Kat Joyce:

Theodor,

The Logs you mention as missing from the page are not.  The are listed under 'Disqualified from Chrome'.  If your script is reporting that they are missing then it is an error on your end, not ours.

The Chrome CT Policy itself does not define official states.  We do plan to externally define official states that a Log can be in in the future as part of the work to expand the current JSON schema (see my previous message in this thread), but, as I mentioned, that is future work that is unlikely to be done soon.  For now the headings displayed on that page are meant simply as an indication of what has happened to the Log wrt inclusion in Chrome, and may change in the future.

Wrt the two headings you specifically ask about, Logs that have been rejected by Chrome were exactly that - rejected for inclusion in Chrome, so never made it in to Chrome as a trusted Log.  Logs that have been distrusted by Chrome were previously trusted, and were then completely removed from Chrome's list of trusted Logs.

Kat

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.