Dave Thompson <[email protected]> wrote: > A quick read through the 7.1.1 ATS code for OCSP handling, looks like we're > using the OpenSSL API to handle interaction with CA, and then passing the > response into our OpenSSL context for stapling in handshake. So, I > believe the SCT is in the CA's response, though to ATS the response is an > unparsed, effectively opaque data buffer, it passes along to/from the > various OpenSSL API's.
Yeah, I did some more reading, too, and OCSP is a no-work-needed approach for ATS (just like if the SCTs are included in the cert). This works well for e.g. DigiCert and Symantec, which both support CT via either x509 or OCSP (or both). I still believe it would be useful for ATS to support CT via the TLS extension. For example, Let's Encrypt does not currently support CT in certs nor via OCSP, so for all the millions of sites using LE, a TLS extension is currently the only option to enable CT. > Regarding Expect-CT header, perhaps header rewrite plugin might be a good > way to enable. Yes, that would work. However, I view Expect-CT to be similar to HSTS in functionality and complexity. Since ATS supports HSTS via a config option, it seems reasonable to me as a user to expect to be able to set the Expect-CT in similar manner without having to fall back to a header-rewrite plugin. -Jan
