On Thu, Feb 6, 2014 at 1:51 PM, Rick Andrews <rick_andr...@symantec.com> wrote: > Can you clarify something? The SCT delivery options described in the RFC are > options for the web site owner, not for the CA. CAs will need to support all > three options. We will have customers who won’t do stapling and can’t handle > TLS extensions, so they just want the SCTs embedded in the cert. But not all > customers will prefer that option. I believe other customers will want the > SCT-in-the-OCSP-response or TLS extension option, because in those options > you don’t have to transmit the SCTs in every SSL handshake. I suspect some of > our large customers who are obsessed with performance will demand one of > these options. > > So CAs will need to support all three options, unless you’re so small a CA > that your few EV customers agree on one option. Is that your expectation?
SCTs embedded in the certificate won't be sent for resumption handshakes of course. The TLS extension will be sent in the same cases as SCTs embedded in the certificate. (And the TLS extension doesn't need the CA to do anything.) The stapled OCSP response is likely to be sent in the same cases also. One could imagine a client that doesn't request a stapled OCSP response when it has a cached OCSP response for the certificate that it saw from the server last time. But, if the server responds with a different certificate it's stuck. So I expect clients to always request the OCSP staple. So a CA only really need worry about the embedded case. Customers who are concerned about the performance impact of a few hundred extra bytes very likely have much easier avenues to reduce the size, like having different certs for different names rather than dozens of SANs. Cheers AGL _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey