Apologies, I was skimming messages too fast and misinterpreted this one. We’re not planning to offer embedded SCTs by x509v3 extension anytime soon. We’re going to stick with the OCSP stapling method for now.
Well, although my preference would be a x509v3 extension, it shouldn’t really matter: OCSP Must Staple is on the horizon and everyone in “TLS land” should be eager to implement it (because revocation checking is de facto defunct as it is right now…) So I’m good with the OCSP stapling method. Hopefully https://github.com/letsencrypt/boulder/pull/1224 can land soon!
Unfortunately, my feature request for Chromium isn’t really taking off…
My understanding is that Let’s Encrypt is not very interested in precertificate-based SCT stapling since it requires each certificate to be issued twice, putting pressure on HSMs.
Currently, only 3⅓ % of the load on the Intermediate cert HSM would be for signing the original certificate. 96⅔ % of the load comes from OCSP signing. (OCSP is signed every 3 days, 90 days lifetime = 30 OCSP signs per certificate, compared to 1 signing of the certificate itself.) So if you’d increase the original certificate signing with one, i.e. doubeling it, it would approx. require 6.5 % of the load (2:31) compared to 93.5 % for the OCSP signing in that scenario.
Ofcourse, there would be some increase in pressure, but would it matter a lot, if you look at those numbers?
FYI for anyone coming across this thread today, the answers have changed. We never implemented OCSP-based SCT delivery. We did implement precertificate-based SCT delivery. More discussion at Generate a certificate without Certificate Transparency.