Policy change preview (before 2028 shards)
Hubert Chao
Hi all,
While Chrome won't put out a call for 2028 log shards until the new year, we want to give a preview on upcoming changes to the CT log policy that will require action before 2028 log shards are accepted.
At present, adding new logs is a manual process. As certificate lifetimes shorten, we're keen to reduce the operational burden both for us and log operators. As a result, we'll be requiring log operators to adopt Apple's proposed JSON metadata to enable automated ingestion of log shards.
We'll make a follow-up announcement when the changes are finalized and live, but log operators should expect that...
Starting November 1, 2026, logs submitted for inclusion will be required to serve an updated log-specific JSON schema. This is only a small delta from the current requirement.
Starting February 1, 2027, log operators will be required to host an operator-specific JSON that enumerates their logs. Logs will be submitted for inclusion by updating this file rather than via the existing process in the bug tracker.
Existing log operator bugs will still exist, both as a venue for providing per-operator JSON URLs and as a communication channel between Chrome and the log operator.
Once we announce the policy change (expected in August), we'll be happy to accept per-operator JSON files at any time (preferably long before the February 1 deadline). We're currently expecting to use JSON schemas compatible with those proposed in Apple's document. If you'd like changes to those schemas, now would be a good time to propose them.
We'll follow up with a full announcement in August, but questions are always welcome,
Hubert, on behalf of the Chrome CT Team
Filippo Valsorda
--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.
Pim van Pelt
Hoi folks,
I've updated tesseract-genconf to emit the new JSON format [commit] for those of us running TesseraCT logs. You can see them now on Halloumi and Lipase, for example:
https://halloumi2028h2.mon.ct.ipng.ch/log.v3.json
Implementing this, I had a little heartburn.
1) We now have two ways to specify endpoints: `submission_url` and `monitoring_url` to satisfy Chromium [ref] and `submission_endpoint.url` and `monitoring_endpoint.url` to satisfy Apple.
2) We have two ways to specify MMD: `mmd` to satisfy Chromium, and `mmd_seconds` to satisfy Apple.
Can we agree on one way to specify endpoints and merge delay for Static CT Logs, or agree to try to not duplicate/diverge fields in the schema in future revisions?
I thought a bit about Filippo's request for multiple operator-list.json, and IPng is in the same boat. As an operator of multiple implementations, we are currently hand-crafting our global operator list:
https://ipng.ch/assets/ct/operator-list.json
If we could export two sets, then I could update tesseract-genconf to emit a generated one for all TesseraCT shards, and ride on Sunlight's output for those shards. I second the request. Counter-argument is it will make it harder to see the operator's full list if we don't have a list-of-lists somewhere.
On the topic of operator-list-v1, I noticed the proposal points to $schema https://www.certificate-transparency.org/schemas/operator-list-v1.json which does not (yet) exist. Double checking: do we want to publish the JSON with or without the $schema field?
groet,
Pim
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/67b13d60-04ba-4062-bb43-50c579e2adde%40app.fastmail.com.
-- Pim van Pelt PBVP1-RIPE - https://ipng.ch/