Signature for all_logs_list.json?

[Aaron Gable]

Hi there,

The known logs page provides links to (the v2 versions of) a few critical files:

- the log list JSON Schema (log_list_schema.json)

- the list of all currently known logs (all_logs_list.json)

- the list of logs currently trusted by Chrome (log_list.json)

- a signature over the file above (log_list.sig)

- the public half of the keypair used to produce the signature above (log_list_pubkey.pem)

However, there does not appear to be a signature over all_logs_list.json (which would presumably be called all_logs_list.sig).

Is there any chance that we could get the all_logs_list file signed in the future? This would make automatically consuming and updating that file much easier to trust.

Thanks,

Aaron

P.S. Also the known logs page should probably be updated to point at the v3 versions of the files.

[Devon O'Brien]

Hey Aaron,

Adding the detached signatures for all_logs_list is something we should be able to accommodate, but out of curiosity, what is your use case for validating this file? Publishing it on gstatic alongside log_list.json was intended more as an informational convenience, which is why we sign and publish the signatures for one and not the other.

I'll also submit a PR to the community site repo to update to the new list versions and clean up some of that text so the team running that site can approve and publish. Thanks for spotting that!

-Devon

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAEmnErdiSKZwVEwQDyQ%3DLEJPvq8rgOXK78d__-DSeDFKFzbqRQ%40mail.gmail.com.

[Aaron Gable]

Yeah, happy to provide context!

We're currently in the process of updating Boulder to be able to enforce the new Chrome CT Policy, rather than the old "one Google log" policy. As part of that process, we've decided to write a lint which checks that the SCTs embedded in a cert come from at least two different log operators. Since the log_list.json and all_logs_list.json files are the only "canonical" mappings of operators to logs, we have to consume one of those files in order to make the lint as accurate as possible.

Since we'll be consuming one of those files anyway, we've also decided to update the way we configure what CT logs we submit to. Currently, that configuration looks something like this. It's very verbose and prone to copy-paste errors. Instead, the new configuration is going to simply list names (technically, Descriptions) of logs, and the rest of the log details (including what operator runs it) will be looked up from the log list file. This will be much more human-readable and much less error-prone. However, we like to also submit precertificates to Pending logs such as Yeti 2022-2 to help them have useful traffic during the qualification process. Because these logs are not yet trusted by Chrome, they do not appear in log_list.json, so we must consume all_logs_list.json for this purpose.

I hope that context helps! Thanks,

Aaron

[Alex Cohn]

The only concern I have with signing all_logs_list.json is that an attacker could potentially pass it off as log_list.json if it were signed with the same key. 

Alex

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

[Devon O'Brien]

Aaron -- Ah, makes sense; we've long wished CAs would submit precerts to pending CT logs to help evaluate them before they become Qualified, especially for CT logs from new log operators. This is, in my opinion, compelling enough to explore signing all_logs_list.json in addition to log_list.json.

Alex -- While I agree that signing both files with the same key could allow a party to mistakenly use all_logs_list.json in lieu of log_list.json, and in general I'm supportive of using cryptographic boundaries like this, it's not clear to me that we get a huge amount of value from this separation here. Both files are kept up to date with an accurate representation of CT logs and their states; signing these files provides authenticity, but does not protect against someone reading either of the lists and their respective states incorrectly.

As a concrete example: Retired CT logs are in both lists. Retired CT logs can have compromised keys that would be bad to rely on as Qualified/Usable regardless of which list you read them from: Retiring a CT log is the action we take when a log is suspected to have been compromised or is known to have misbehaved. Also, Retired CT logs aren't required to continue operation and are thus not able to be reliably monitored (https://goo.gl/chrome/ct-log-states).

While all_logs_list.json contains several additional logs that were specifically never recognized in Chrome, I'm not entirely sure that signing these with a different key (and requiring the consumer to use the correct key for their use case) provides a compelling set of protections from misinterpreting the log states that are accurately reflected in both lists. In case I missed the crux of your concern, is there a failure mode from signing these lists with the same key that doesn't rely on misinterpreting the lists' content?

[Pavel Kalinnikov]

I think using different keys isn't the only way to mitigate this concern. If the content/schema of all_logs_list.json is distinguishable from log_list.json, then the swapping wouldn't be possible. For example, if there is some "salt" field in the JSON which says "this is the official list" vs "this is the full list", then it's good enough.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAD2nvsTtHFawNFvQc-q0Pav9W3TFFPxdriNrV6ujXA1%2B-%2B4r2w%40mail.gmail.com.

[Alex Cohn]

I'm mostly concerned that, given a signed list, there should be some way to tell which list it is; I don't have a specific attack in mind. Pavel's suggestion of a "salt" log list identifier field would effectively mitigate my concern.

Alex

[Aaron Gable]

Why does it matter which list it is? The existence of log_list.json is basically just a bandwidth-saving convenience: Chrome clients could pull the full all_logs_list, filter out the logs with unacceptable statuses, and get the exact same result.

The only situation in which it matters what list you have is if you're ignoring the Status field of each log. And if you're doing that, then why would we believe that signing with a different key, or including a sentinel field, would make any difference?