This is a really good idea.<p>> while it does not protect against a compromised CA<p>Although it does <i>prove</i> that a CA has been compromised. That significantly raises the kind of "compromise" that the CA would need to have suffered.<p>...<p>It may confuse people that you have chosen a name which affiliates your proposal with something ("Expect-CT") which was recently deprecated.<p>I also suggest simplifying it to merely require method (1). In other words: "non-browser TLS clients should require an embedded SCT (RFC 9162 section 7.1.2)".<p><a href="https://datatracker.ietf.org/doc/html/rfc9162#section-7.1.2" rel="nofollow noreferrer">https://datatracker.ietf.org/doc/html/rfc9162#section-7.1.2</a><p>Requiring that a non-browser TLS client implement OCSP is a pretty big burden. Since OCSP uses HTTP this imposes a "must speak HTTP" mandate on all TLS clients! HTTP has become an incredibly complex protocol over the years. It would also make me very uneasy if all of my TLS client software had to have the ability to reach out and contact arbitrary servers.<p>Perhaps even: "newly-introduced TLS-based protocols should require that clients reject server certificates which lack an embedded SCT, but the client need not validate the SCT".