I'm trying to understand the mechanism and agreements between CAs and CT log operators/organisations that result in a CA submitting entries to a log - I understand from RFC6962/9162 the protocol for submitting an entry, and I understand the policies browser providers apply (e.g. Chrome, Apple ) but I can't find any documentation that describes how various CAs such as Let's Encrypt select and accept which specific logs to submit too, and how those log providers accept entries from those CAs? Similarly I'm having a hard time finding anything that describes if/how log operations share certificate information between them e.g. if a CA submits to 2 different logs, could a third log also end up holding information about certificates that CA issues without the CA directly submitting?
I felt I had an intuition for this (e.g. this was all based on offline agreements between CAs and log operators) but I recall reading about CT logs, admittedly from a few years ago, operated by individuals to demonstrate CT log operation e.g. the"behind the sofa" CT log - this log is offline and long retired (but does still show on the history list alongside others on https://crt.sh/monitored-logs ) - how would this have worked? Did the operator of that log make agreements with CAs to have submissions sent to them? This feels unlikely, but I can't find a clear explanation of how this works in practice, either in the past, or today?
As far as I know, log operators can define policies as they wish. Let's Encrypt has statements like this in their submission applications:
This is the first Let’s Encrypt CT log. It is open to all publicly trusted Certificate Authorities. Publicly trusted means that we will accept submissions from any CA in the Mozilla NSS root store and the Apple iOS Trust Store. We will update to the latest root store upon request from a CA or the general public, or periodically at our discretion.
The log shards are public and provides open access. There are no fees for submitting certificates or any other usage, including queries and mirroring. No prior contracts or agreements are required before the log shards may be used.
Other CT logs have similar statements. Effectively, anyone can submit a certificate to any log as they wish.
There's no communication between logs. A third party can submit certificates to any log at any time (in fact, in the early CT days, Google used to operate crawlers that did exactly this). The CA doesn't have to be the one that submits the cert (though nowadays they usually do, to get the SCTs).
The CA submits to any log they like. Many submit in some round-robin fashion, maybe with preferences included. The CT log accepts any certificate signed by a root that's trusted by the log (and that fits the logs inclusion criteria, usually expiration date). The list of certificates trusted by the log is published in certain places, like the CT log submission applications.
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. Note: This restriction may prevent a CT Log from being accepted by Chrome for inclusion.
Ok - I think this has clicked into place for me...
log operators elect to accept SCTs and resultant certificates only when signed from accepted CA roots, but they don't care who actually submits them
the CA roots they accept are based on alignment with browser root programmes, and it also applies in reverse, browsers have log policies that expect log alignment to their root programme lists
anyone can operate an independent log if they chose to, and they can scrape other logs to populate theirs, but CAs aren't going to bother submitting to some random log, and browsers aren't going to accept SCTs signed by some random, non-policy-compliant log
CAs may (and do) choose to submit SCTs to a variety of logs as they seem fit (just looked on the Merkle Town site, this shows the spread of prominent CAs across a variety of different logs)
Thanks for the replies - has really helped me understand this.
SCT (signed certificate timestamp) is the thing that a log hands back to whoever submitted the certificate. So a log doesn't accept SCTs, it issues them (it accepts certificates). An SCT is a "promise" of the log to include the certificate within the Merkle tree in <= the maximum merge delay time. Violating this promise is grounds for disqualification of the log, and regularly verified by monitors.
This is all spot on, yes.
Replace SCT with certificate and its fits as well.
Your post shows you understand those dynamics now. This is essentially just CA/B Forum members doing transparent data sharing - the Browsers are requiring public submissions to trusted log operators, and the CAs are required to submit to them (for the pre-certificate signing). Secondary logs and data feeds do exist, but they're really for research.