Understanding use-cases for SCTs delivered via OCSP stapling for TLS extension

Skip to first unread message

Joe DeBlasio

Jan 27, 2023, 6:31:34 PMJan 27
to Certificate Transparency Policy

Hi ct-policy@,

Chrome is looking to better understand active use-cases of SCTs delivered via OCSP Stapling and/or TLS extension (i.e. not embedded in the certificate).

Though these mechanisms are included in RFC 6962, current use is extremely low. Supporting them contributes significant complexity to Chrome's certificate validation pipeline and CT processes.

If your, or your clients', processes necessitate the use of these mechanisms, we'd like to learn more! Replies to this post on-thread are great, but if you'd prefer, you can also reply to me directly.



Joe DeBlasio

Feb 9, 2023, 3:38:14 PMFeb 9
to certificate-...@googlegroups.com, Certificate Transparency Policy
Hi all,

Based on the response so far, we'll be investigating removing support for one or both of these SCT delivery mechanisms in Chrome.

This may be your last opportunity to influence our decision -- please reach out on thread or privately if you or your customers can't easily migrate to using SCTs embedded in the certificate, or if you think maintaining these delivery mechanisms are essential for other reasons.


On Mon, Jan 30, 2023 at 1:27 AM 'Pierre Phaneuf' via certificate-transparency <certificate-...@googlegroups.com> wrote:

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S5CQ8_v7-Sb3oJo8SmUkkA9AM7pPj%2Bc4s4z5SX-euU9_w%40mail.gmail.com.

You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/CAKMqHLgDihdsJEcaCZURDEzTYqmxvrVNuBbxXs5bSpAkNwiEHw%40mail.gmail.com.

Nick Sullivan

Feb 9, 2023, 3:53:02 PMFeb 9
to Joe DeBlasio, certificate-...@googlegroups.com, Certificate Transparency Policy
Hi Joe,

We (Cloudflare) got this email a while back but have been delayed in formulating a response. We currently support SCT-in-TLS and automatically check certificates against all client policies so that we can make sure every connection to Cloudflare is SCT qualified for all clients. I'm including a short summary of our position here. Other team members may have some things to add.

This mechanism isn’t commonly used at the moment for many certificates, but it’s not intended for use in typical circumstances where policies are stable. The benefit of this mechanism is to help keep the PKI working on CT-validating browsers when policies change or diverge between multiple clients. We consider it a strong insurance policy for when clients disagree about CT policy or CAs are slow to update their SCT inclusion policies in response to client policiese. Two log disqualifications without a swift and immediate move from CAs to stop using them may result in a many certificates causing errors in browsers without SCT-in-TLS as a remediation mechanism.

It might be helpful to crawl through the CT Monitor data, and calculate how many certs would have to be reissued should Chrome proceed with dropping stapled SCT support. We currently have a “CT-Qualified Cert” status on https://ct.cloudflare.com/ that is supposed to show how many certs are accepted by Chrome CT policy, but it is not entirely accurate due to changes to the policy that have not been implemented yet.

Not having in-TLS SCTs as a backup puts the ecosystem at risk and gives us no way to remediate issues due to CAs not using the “right” SCTs at issuance — something that seems very likely. In our opinion, it would be a big setback.


Susan Ven

May 31, 2023, 10:39:02 PM (yesterday) May 31
to Certificate Transparency Policy, Nick Sullivan, Joe DeBlasio
Hi Joe,

A few months have passed, has your team decided to continue supporting both SCT delivery mechanisms? Or has the decision been made to remove that support soon? Are there any publicly available statistics on how many servers still rely on these two SCT delivery mechanisms? I'm very curious about the current usage of both mechanisms, and I've searched the web and can't find even one example of SCT delivery based on OCSP Stapling.

Best wishes,

David Adrian

Jun 1, 2023, 4:48:24 PM (13 hours ago) Jun 1
to Susan Ven, Certificate Transparency Policy, Nick Sullivan, Joe DeBlasio
We don't have any concrete plans at the moment, but if we did anything, it would likely be to drop support for SCTs-via-OCSP, especially if SC-63 passes in the CA Browser Forum. This drastically simplifies log list changes, as you don't have to worry about cached OCSP responses.

Joe DeBlasio

Jun 1, 2023, 6:10:24 PM (12 hours ago) Jun 1
to David Adrian, Susan Ven, Certificate Transparency Policy, Nick Sullivan
tl;dr: what David said. :-)

Apologies for disappearing for a while!

Firstly, I appreciate Nick's points on why Cloudflare considers SCTs delivered via TLS to be a worthwhile safety mechanism (and thank you for responding to my intentionally-provocative email). That said, from the perspective of a user agent, it's very hard to envision a scenario where a log distrust or similar action could be sufficiently mitigated by SCTs delivered via TLS. Most sites won't have done the engineering effort to support SCTs via TLS. A few large players (e.g. Cloudflare) will have, but if impact was limited to those actors, those same entities would likely be able to assist in certificate reissuance. Conversely, if the impact wasn't limited to just those few large players, we wouldn't be able to rely only on SCTs over TLS as a sufficient mitigation. Instead, user agents would need an approach inclusive of the majority of the sites that would need a different approach to avoid large scale breakage. Either way, SCTs over TLS probably aren't the best tool.

Having said all of that, as David noted, SCTs via OCSP introduce significant greater complexity from a policy perspective, and have considerably lower usage. It's true that we have no immediate plans to announce, but removal of OCSP-stapled SCTs is high on my personal wishlist. As I noted above, I'm not personally convinced by the value of SCTs-via-TLS, but the picture is undeniably more complicated and I don't expect to push that issue any time soon.

Hope that helps,

Susan Ven

Jun 1, 2023, 10:54:22 PM (7 hours ago) Jun 1
to Certificate Transparency Policy, Joe DeBlasio, Susan Ven, Certificate Transparency Policy, Nick Sullivan, David Adrian
Thank you for the above response, and I will continue to follow this topic.
Reply all
Reply to author
0 new messages