Proposal for CT Operator-published log metadata

[Clint Wilson]

Hello all!

Building on the fantastic work that’s occurred over the last year to provide more robust information about the state of CT Logs, such as https://googlechrome.github.io/CertificateTransparency/inclusion_request_schema.json and https://github.com/FiloSottile/sunlight/commit/49406f3a7f9339c4554ed0f94db6d2e8f2e46575, we want to propose a further evolution of CT Log metadata published by Log Operators to support additional automation within the CT Ecosystem.

The proposal is shared here: https://docs.google.com/document/d/1KIBO8OjTHcmf6e2OsEGYanovC9LWIQL6sS9N8XODmt4 and should be publicly accessible and allow comments from anyone.

We’d love to hear your thoughts on this proposal, from Log Operators, Monitors, technology maintainers, Log Programs, and interested parties or other stakeholders.

Thank you!

-Clint

[Matthew McPherrin]

In order to be able to try out the schemas and read them in something with nicer indentation than the doc, I've checked the schemas and examples into a repository at https://github.com/mcpherrinm/ctmeta

There is also a schema verification tool included now, and depending on how the discussion goes, may add a few more small tools for working with these files.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/32B00CE7-D981-4253-A18C-5AB45EC1ECCA%40apple.com.

[Clint]

Hello everybody!

I've attempted to address all comments submitted to the Google doc. I've updated it accordingly here: https://docs.google.com/document/d/1KIBO8OjTHcmf6e2OsEGYanovC9LWIQL6sS9N8XODmt4/

I've also submitted a PR to Matthew's repo for easier comparison: https://github.com/mcpherrinm/ctmeta/pull/1

Thank you all so very much for the feedback thus far!

-Clint

[Filippo Valsorda]

Hi Clint,

I have implemented the new schema in

https://github.com/FiloSottile/sunlight/pull/62

and deployed it to staging. You can see the Sunlight metadata at

https://skylight.geomys.org/logs.json

https://navigli2026h1.skylight.geomys.org/log.v3.json

The only thing that wasn't clear to me was the decommissioned intended_use. It felt redundant with status: inactive, and a loss of information on the previous purpose of the log. When would an operator set intended_use to decommissioned and status not to inactive?

Cheers,

Filippo

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/6091543f-2758-40fd-86b3-a16c6aabc07fn%40chromium.org.

[Andrew Ayer]

On Fri, 17 Apr 2026 12:55:14 +0200
"Filippo Valsorda" <fil...@ml.filippo.io> wrote:

> I have implemented the new schema in
>
> https://github.com/FiloSottile/sunlight/pull/62
>
> and deployed it to staging. You can see the Sunlight metadata at
>
> https://skylight.geomys.org/logs.json
> https://navigli2026h1.skylight.geomys.org/log.v3.json

I like the way this looks, except for the duplication of the URLs:

"submission_url": "https://navigli2026h1.sunlight.geomys.org/",
"monitoring_url": "https://navigli2026h1.skylight.geomys.org/",

"submission_endpoint": {
"url": "https://navigli2026h1.sunlight.geomys.org/"
},
"monitoring_endpoint": {
"url": "https://navigli2026h1.skylight.geomys.org/"
},

I also just noticed that there's no way for an RFC6962 log to declare different rate limits for the monitoring and submission endpoints.

I propose:

1. Add submission_url, monitoring_url, and url to the top-level log object, for compatibility with the original log list schema.

2. Add monitoring_rate_limit and submission_rate_limit to the top-level log object.

3. Remove submission_endpoint, monitoring_endpoint, and endpoint from the top-level log object.

I also agree with Filippo's comments about intended_status=decommissioned.

Regards,
Andrew

[Rob Stradling]

Some log operators have (or have had?) rate limits that are applied across a set of logs rather than to individual logs.

Would it make sense to have a rate limit section in the Operator List object, where each such limit would have an associated "base URL" or perhaps even a regexp?

---

From: ct-p...@chromium.org <ct-p...@chromium.org> on behalf of Andrew Ayer <ag...@andrewayer.name>
Sent: 17 April 2026 12:42
To: Filippo Valsorda <fil...@ml.filippo.io>
Cc: Clint Wilson <cli...@apple.com>; Certificate Transparency Policy <ct-p...@chromium.org>; Matthew McPherrin <ma...@letsencrypt.org>
Subject: Re: [ct-policy] Proposal for CT Operator-published log metadata

 

On Fri, 17 Apr 2026 12: 55: 14 +0200 "Filippo Valsorda" <filippo@ ml. filippo. io> wrote: > I have implemented the new schema in > > https: //urldefense. com/v3/__https: //github. com/FiloSottile/sunlight/pull/62__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7YSR9Low$

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

On Fri, 17 Apr 2026 12:55:14 +0200
"Filippo Valsorda" <fil...@ml.filippo.io

> wrote:

> I have implemented the new schema in
> 
> https://urldefense.com/v3/__https://github.com/FiloSottile/sunlight/pull/62__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7YSR9Low$
> 
> and deployed it to staging. You can see the Sunlight metadata at
> 
> https://urldefense.com/v3/__https://skylight.geomys.org/logs.json__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7CpWXMsY$
> https://urldefense.com/v3/__https://navigli2026h1.skylight.geomys.org/log.v3.json__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7Nm_fQYw$

I like the way this looks, except for the duplication of the URLs:

    "submission_url": "https://urldefense.com/v3/__https://navigli2026h1.sunlight.geomys.org/__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7-CCwcdA$",
    "monitoring_url": "https://urldefense.com/v3/__https://navigli2026h1.skylight.geomys.org/__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7zJK8KtI$",

    "submission_endpoint": {
        "url": "https://urldefense.com/v3/__https://navigli2026h1.sunlight.geomys.org/__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7-CCwcdA$"
    },
    "monitoring_endpoint": {
        "url": "https://urldefense.com/v3/__https://navigli2026h1.skylight.geomys.org/__;!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7zJK8KtI$"
    },

I also just noticed that there's no way for an RFC6962 log to declare different rate limits for the monitoring and submission endpoints.

I propose:

1. Add submission_url, monitoring_url, and url to the top-level log object, for compatibility with the original log list schema.

2. Add monitoring_rate_limit and submission_rate_limit to the top-level log object.

3. Remove submission_endpoint, monitoring_endpoint, and endpoint from the top-level log object.

I also agree with Filippo's comments about intended_status=decommissioned.

Regards,
Andrew

-- 
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20260417074229.50717b1ff5fe0c814f87ee2a*40andrewayer.name__;JQ!!J5K_pWsD!wzhr5xZVsEc8bd1ol-KU4h51kC0kmDGCGGGz6pxgvQdvPrp9aLzGFaLG1RolqZMTlS7V-hP7LZ0a8ek$.

[Matthew McPherrin]

Thanks, I've added a few small changes and merged the PR.

I'm much happier with the split between the two files now!

[Matthew McPherrin]

I've added a bit more sample data, and hosted it all on Github Pages with an index to get a feel for the data:

https://mcpherrinm.github.io/ctmeta/

https://skylight.geomys.org/logs.json is missing an operator name, so I've added that to the version in this sample data.