attaching a signed certificate timestamp (SCT) to a certificate using an X.509v3 extension or
enabling the client to deliver SCTs by using a special TLS extension or
using Online Certificate Status Protocol (OCSP) stapling?
In contrast to the last two mechanisms, X.509v3 extension does not require any server modification, whereas OCSP stapling does not delay the issuance of the certificate, since the CA can get the SCT asynchronously.
We’re planning to submit certificates to CT logs, which we think is the most important part: being transparent and open about the certificates we issue, and allowing the public to research and analyze them. If we provide SCTs, it would be via OCSP, definitely not by X.509v3 extension. But we’re not yet sure if we’ll provide SCTs via OCSP at launch. In particular, necessary support for OCSP extensions seems to be absent from Golang. However, subscribers who want to provide SCTs with their certificates should be able to fetch them directly from the CT logs and provide them via TLS extension.
Using x509v3 extensions would require that we block issuance of a certificate on the retrieval of some pre-determined number of SCTs, whereas storing the SCT in OCSP responses allows us to issue a certificate asynchronously of this process. Additionally verification of SCTs embedded in OCSP responses is handled in the same manner as those embeded in x509v3 extensions, so no extra client configuration should be necessary.
I agree with this! It seems very painful to set up webserver to deliver sct via TLS extension, and OCSP requires the CA to enable this for SCT, which LE may do at launch, if at all. OCSP also require OCSP stapling on the server, and to use the OCSP extensions.
I agree that it’s painful to set up a webserver to deliver SCT vis TLS extension. However, keep in mind that, for now, browsers do not do anything with attached SCTs for non-EV certs. That’s why we’re focusing on log submission right now.
It’s significantly more complicated than it sounds, actually. I’d encourage you to read the relevant section of RFC6962. In effect, the CA has to issue the certificate twice. First you generate a precertificate with a critical poison extension, then submit it to a CT log, receive the SCT, and then sign it again. There is potential for failure and delay at each step in the process, plus significant additional complexity, which is why the authors of the CT spec included easier options.
Also note that currently if you want Apache to serve SCTs you must use a patched version built from source as the stable branch doesn’t have these features yet, making it even harder for the LE client to try to set this up.
You’re right in the sense that browsers don’t require CT for non EV certificates, but chrome does show whether any DV/OV/EV certificate is supplied with valid certificate transparency information.
And also allows you to view this transparency information: Screenshot
[quote=“jsha, post:2, topic:222”]
If we provide SCTs, it would be via OCSP, definitely not by X.509v3 extension. But we’re not yet sure if we’ll provide SCTs via OCSP at launch. In particular, necessary support for OCSP extensions seems to be absent from Golang.[/quote]
There is no “SCT via OCSP” as of now…
Does LE wait for “Golang to support OCSP extensions”?
Or it is “low priority thing” (and as such has no ETA at all)?
It’s not a complaint, just wondering, what’s the plan on it
[quote=“tlussnig, post:16, topic:222, full:true”]
Hi, it is wrong defined there is an definition how CT can be provided by OCSP-Stapling.I think this was what je meant with OCSP.
[/quote]I’m referring to https://www.certificate-transparency.org/how-ct-works OCSP Stapling paragraph.
I.e. once LE adds SCT to its OCSP response, a client will get it too (via OCSP Stapling)
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!
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?