Hello, I am quite late to the party on this thread, but having recently implemented a CT log (https://github.com/Barre/compact_log), ekr's blog post was actually one of the things that I had on my mind while designing.
Reading his post, most of the issues he raises are about specific implementation choices. The SCT-as-promise problem exists because traditional logs issue SCTs immediately then incorporate certificates later. CompactLog does it the other way around - certificates go into the Merkle tree first, then issue the SCT. Zero MMD, no promises involved. Same with the operational complexity - logs struggling with 24-hour deadlines and having outages. CompactLog handles 3-4K certificates/second with P99 latencies under 1 second, no background processing needed. The synchronous design eliminates entire classes of timing-related failures. The one valid criticism that remains is browsers not verifying inclusion proofs by default. But there's an interesting middle ground here: systematic cross-validation between logs. Since browsers already require 2-3 SCTs from different logs, certificates are seen by multiple logs anyway. When Log A sees a certificate with SCTs from Logs B and C, it can verify that certificate actually appears in their trees. This changes the attack model significantly - instead of just finding 2-3 colluding logs, an attacker must ensure their phantom certificate *never* reaches any honest log through monitors, crawlers, or third-party submissions. With 6 trusted logs, attacking a system requiring 2 SCTs means evading detection by all 4 non-colluding logs indefinitely. Combined with domain-specific monitoring, this creates multiple independent detection layers without the privacy concerns of client-side verification. >From an implementer's perspective, CT delivers what it promises - a verifiable log of all certificates. The fact that browsers choose to trust SCTs rather than verify proofs doesn't diminish the value of having that verifiable log. Best, Pierre On Tuesday, February 4, 2025 at 11:50:00 PM UTC+1 Jeremy Rowley wrote: > I realize ekr is no longer part of Mozilla, but I am wondering on your > thoughts on his previous dislike for CT? > https://educatedguesswork.org/posts/transparency-part-2/ > > How did you overcome his criticisms? Did Mozilla just accept the CT > shortcomings? I like CT personally, but I found his criticisms interesting > and wanted to hear more about any discussion/decisions related to them. > > Congrats as well! > > On Tue, Feb 4, 2025 at 2:51 PM 'Jan Schaumann' via > [email protected] <[email protected]> wrote: > >> Dana Keeler <[email protected]> wrote: >> > > Could you clarify how this applies to custom CAs? >> > >> > For CAs that are not part of Mozilla's Root CA program (in other words, >> CAs >> > that are not built-ins shipped with Firefox), no certificate >> transparency >> > information is required (in other words, for your custom CA, no action >> > should be needed). >> > The use of policies to exempt internal certificates or domains applies >> to >> > situations where a publicly-trusted CA was used to issue certificates >> for >> > domains that are intended to be internal to an organization. >> >> Thanks, that makes it clear. >> >> -Jan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/Z6KL1PP89G61L92e%40netmeister.org >> . >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8939046b-3490-48a1-b145-a642c2c36bf6n%40mozilla.org.
