I feel like it would be great if CAs that encoded invalid SCTs could proactively file incident reports, regardless of whether we conclude they are required to do so or not.
It’s clearly an unintentional technical outcome that the community could learn from, and I trust that root programs would have *more* confidence in a CA that takes the issue seriously and formulates an effective remediation plan, than in one that avoids filing the incident report. 2025-12-13 13:09 GMT+01:00 'Rob Stradling' via [email protected] <[email protected]>: > > 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 > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729252D77B355DDB26E5920AAAFA%40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer>. -- 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/9d931bf0-26b3-4c64-8f19-afc759433787%40app.fastmail.com.
