> I never said that this was a BR / root store policy violation. I agree that neither the TLS BRs nor any root store policies require an SCT List extension to be present in any leaf certificates. However, for every case where an SCT List extension is present in a leaf certificate...
> I also think that maybe it *should* be a root store policy violation if a > certificate has an SCT extension but doesn't comply with CT policy. ...TLS BR 7.1.2.11.3 (Signed Certificate Timestamp List) requires: "If present, the Signed Certificate Timestamp List extension contents MUST be an OCTET STRING containing the encoded SignedCertificateTimestampList, as specified in RFC 6962, Section 3.3. Each SignedCertificateTimestamp included within the SignedCertificateTimestampList MUST be for a PreCert LogEntryType that corresponds to the current certificate." https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 requires that: "The SCT data corresponding to the end-entity certificate from at least one log must be included in the TLS handshake, either by using an X509v3 certificate extension as described below..." So, in my view, it is already a TLS BR violation to include an incorrectly-encoded SCT or a for-the-wrong-certificate SCT in an SCT List extension within a leaf certificate. Both categories of mistake that you mentioned - not copying, and not base64-decoding, the SCT extensions - are examples of incorrectly-encoded SCTs in an SCT List extension within a leaf certificate, so they are TLS BR policy violations (and, therefore, they are also root store policy violations). > I'm still observing multiple CAs issuing certificates that do not work in > some browsers (including some Firefox releases that are less than 70 days > old) due to using CT logs that are not broadly Usable. It's worth noting that SCTs from logs that are Qualified (but not yet Usable) do contribute towards CT policy compliance. So even if it did become "a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy", that still wouldn't solve the usability problem of Qualified SCTs being embedded before the log is broadly Usable. Anticipating which logs will become broadly Usable (and when), and determining which logs actually are broadly Usable right now, across all of the CT-enforcing platforms, is a hard problem right now: one vendor's CT log list doesn't distinguish between Qualified, Usable, and ReadOnly; another vendor's CT log list sometimes takes many months longer than expected to move logs from Qualified to Usable. ________________________________ From: [email protected] <[email protected]> on behalf of Andrew Ayer <[email protected]> Sent: 12 December 2025 17:26 To: Jeremy Rowley <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Ongoing CT Logging Mistakes by CAs On Fri, 12 Dec 2025 09: 31: 44 -0700 Jeremy Rowley <rowleylaw@ gmail. com> wrote: > Is this a problem though? > > I'm not sure any browser requires CT logging. The MS policy almost > did but was changed before it became effective. ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!CGYXkEc1_cC4a7Ag-Tgd4K1y2Ak0rsD3_hOawoG3KMH9rSXEjnsa-VfzErQqx4YFMKnyi0tRjdpfVeSZ7XBfZUueG1R_riuYlIqntbm3Xg$> ZjQcmQRYFpfptBannerEnd On Fri, 12 Dec 2025 09:31:44 -0700 Jeremy Rowley <[email protected]> wrote: > Is this a problem though? > > I'm not sure any browser requires CT logging. The MS policy almost > did but was changed before it became effective. > > Apple's policy is close but the stated consequence is: "Certificates > that fail to comply with our policy will result in a failed TLS > connection, which can break an app's connection to Internet services > or Safari's ability to seamlessly connect." This is just fine for > WebPKI that doesn't care about Apple connections. > > CT isn't required in the Chrome policy. > > Mozilla policy doesn't state that CT logging is required I never said that this was a BR / root store policy violation. But that doesn't mean it's not a problem. The affected CAs clearly weren't intending to issue unlogged certificates that don't need to work in browsers, as every affected certificate has SCTs. When the subscriber receives the certificate and finds it doesn't work in all browsers, that's presumably going to be a problem for them. <https://urldefense.com/v3/__https://status.globalsign.com/incidents/49ndl5hz24h2__;!!J5K_pWsD!xqGTsO7CEYdlODDI-tZ7mEDGKH6veCtNPS_kr2sJjT1I58NqfvqKA3UjlCd5VIuTWma35g2rfHYPX8U$> and Alvin's reply confirm that this has been causing subscriber impact. So, I thought CAs would want to know about it, and I think not all CAs are subscribed to ct-policy. I also think that maybe it *should* be a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy. Root stores have an interest in avoiding breakage when they make changes. Unfortunately, without incident reports being required, there's no way to be sure the root cause is being addressed so that changes will be safer in the future. Regards, Andrew -- 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://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20251212122617.3155fa43ed3049ffaa81a28a*40andrewayer.name__;JQ!!J5K_pWsD!xqGTsO7CEYdlODDI-tZ7mEDGKH6veCtNPS_kr2sJjT1I58NqfvqKA3UjlCd5VIuTWma35g2rtfS7Z1E$. -- 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/MW4PR17MB4729252D77B355DDB26E5920AAAFA%40MW4PR17MB4729.namprd17.prod.outlook.com.
