Upcoming policy and log list schema changes to support static-ct-api logs in Chrome

[Joe DeBlasio]

Hello ct-policy@ community!

We will be updating our policies soon to support adding static-ct-api logs as trusted CT logs in Chrome. This email outlines our initial policy and log list schema changes to that end.

Policy changes

To accommodate static-ct-api logs, Chrome's current CT policy will be updated to clarify that at least one SCT must originate from a log Chrome recognized as both Usable and RFC6962 compliant at time of SCT issuance. Our hope and expectation is to remove this "at least one" limitation in a future policy update.

The current log policy will be updated to state that:

• log operators may submit RFC6962-compliant or static-ct-api-compliant logs for inclusion in Chrome's log list, and should specify the log type during the application process,

• we will only consider applications of static-ct-api logs with an MMD of 10 seconds or less, and

• applications for static-ct-api log inclusion will only be accepted from existing log operators if those operators have already applied with an RFC6962-compatible log accepting the same set of certificates (i.e. same accepted roots and temporal window).

This last requirement is to encourage the ongoing health of the RFC6962-only log ecosystem pending greater adoption of the static-ct-log specification among CT monitors. We expect to remove this requirement coincident with the removal of the "at least one" policy described above.

We expect these changes to land shortly after static-ct-api reaches full v1.0 status. Once these changes land, log operators are welcome to apply for inclusion of their static-ct-api logs. However, log operators wishing to submit their static-ct-api-compliant logs should also know that a future log policy update will increase availability requirements on static-ct-api logs for endpoints served via the monitoring prefix. Log operators are encouraged to structure their log such that log contents can remain available in a variety of outage and maintenance conditions.

Log list schema changes

To accommodate tiled logs in our public log list, we will add a new required tiled_logs array to the existing operator object in our public log list schema. The tiled_logs schema will match that of the existing logs array in the same operator object, except that the url field will be omitted, and two new fields, a submission_url and a monitoring_url will be present. These URLs represent the submission and monitoring prefixes defined in the static-ct-api C2SP spec.

Since these changes are purely additive, we expect they will be mostly backwards compatible with existing log list consumers (and trivially adapted if not) and will not be updating the log list URL. We expect this schema change to occur later this week. Simultaneous with the schema update, we will update the published log list with empty tiled_logs arrays for all existing operators.

A note on RFC6962 log requirements

We have received questions regarding whether a static-ct-api log with an RFC6962 compatibility proxy (like Sunglasses) could be accepted as an RFC6962 log in Chrome. Chrome leaves the choice of implementation of logs entirely up to the log operator. However, a log using a given public/private key pair may only apply for inclusion in Chrome as either an RFC6962 or static-ct-api log, even if the log otherwise fully implements both specifications.

Our expectation is that static-ct-api logs providing an RFC6962 API are largely indistinguishable from other RFC6962 logs from the perspective of certificate submitters. However:

• Static-ct-api-backed logs may provide the LeafIndex CtExtension. Well-behaved RFC6962 certificate submitters should be robust to encountering novel extensions.

• The add-chain and add-pre-chain endpoints of static-ct-api-backed logs may have higher latency than typical RFC6962 logs. Though our policy does not currently specify request latency requirements, our monitoring infrastructure does measure it; we may investigate adding latency caps if we determine that significant latency delays are harming the ecosystem.

As always, questions are welcome!

Joe, on behalf of the Chrome CT Team

[Adit Sachde]

Hi Joe,

I am concerned about the 10 second MMD proposed here, as it prevents useful cost optimizations around the handling of partial tiles.

Consider a log that receives 15 certificates a second, about 20% of the current issuance rate. This log will receive 150 certificates in a 10 second interval, so it must produce a partial entry tile to meet the MMD. On average, the partial tile will be half the size of a full tile. Fetching full and partial tiles doubles the requests made to the log and uses 50% more bandwidth compared to just fetching full tiles.

As monitors want to closely follow logs, they do actually fetch these partial tiles instead of waiting a few additional seconds for the full tile to be produced. The log cannot control this behavior and must serve these partial tiles for checkpoints it has signed as per the spec.

If the log instead had a MMD under which it usually receives more than 256 certificates, it is able only sign checkpoints that produce full tiles. This allows it to remain spec compliant while greatly reducing bandwidth and requests, a major cost driver on public clouds.

CT monitors tend to poll logs at most once every 60 seconds. I think a MMD of 60 seconds to match the polling rate would strike a good balance between ensuring that certificates are made available as soon as possible while also allowing most logs to reduce their operating costs.

Best,
Adit

--
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/CAFZs0S4vKgQywCo7_O49%2BbbmU4QAM_Y89Ct8AEnP4-FvZHNSJg%40mail.gmail.com.

[Philippe Boneff]

In practice, based on Merkle Town data, most of the logs that are currently trusted by major clients receive enough write traffic that they will add 256 entries in less than 10 seconds. Given the rate at which CT grows this is likely to remain true.

I do recognize though, that for logs that have low write traffic (e.g. temporal logs that don't receive a lot of traffic yet because they haven't crossed the threshold for 90 days certs, or new log operators in town - yay!, or potentially in a world where there are a lot more CT logs), this is not true. That means more partial tiles indeed, and therefore more requests, and more bandwidth.

The tlog-tiles specs recommends that clients wait for for full tiles if they can, rather than fetching partial tiles, and thus fetching the same data over and over again. Regardless of the MMD, I think this is something we should put in the static-ct specs as well. It's not enforceable, but it's always good to increase visibility around this.

Cheers,

Philippe

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACEYhVCw8zOVqkqJ17QOZuvHzVDxrJyBnq7hYQ3L_BohTsfDhA%40mail.gmail.com.

[Joe DeBlasio - Google]

Thanks Adit and Philippe. These are good callouts.

Just thinking out loud (i.e. nothing I'm saying here is Chrome's policy): One of the properties we like in having a short MMD is that it limits the number of entries that could be lost (or even temporarily unavailable) if the log were to suddenly stop publishing checkpoints. Though I don't think we could enforce it, I'd love to see a "maximum number of outstanding entries". What's more, we agree that few log consumers need to be tailing the log so closely as to be reading partial tiles in normal circumstances, and in general we'd be supportive of many proposals that encourage users to wait.

A log behavior that has nice properties is to publish tiles immediately as soon as they're full, and only publishing partial tiles when necessary to achieve the MMD. If logs behaved like that, I'd personally be completely comfortable with a 60s MMD, since the blast radius would be limited.

We'll keep thinking on this on our side, but I'd be interested in others' thoughts and perspectives on balancing bandwidth usage, reduced MMDs, or other related issues.

Best,

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S4vKgQywCo7_O49%2BbbmU4QAM_Y89Ct8AEnP4-FvZHNSJg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Andrew Ayer]

Hi Joe,

I'm attempting to consume the new "tiled_logs" array in
https://www.gstatic.com/ct/log_list/v3/all_logs_list.json and I noticed
that all of the temporal intervals have a time of 07:00 or 08:00 rather
than midnight as specified by the log operators. Timezone mixup somewhere?

Regards,
Andrew

[Joe DeBlasio]

Thanks, Andrew, and good catch as always. That bug has been fixed and log list should be updated with the new timestamps tomorrow morning.

[Vincent Calderone]

--

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/CAFZs0S6rK2nU06dNUepg7OSSMFUSGbFLct%2Bd6t1%2BywaH3hXKQw%40mail.gmail.com.