Re: [therightkey] Updated Certificate Transparency + Extended Validation plan

[Adam Langley <[e-mail]>]

On Thu, Feb 6, 2014 at 1:51 PM, Rick Andrews <[e-mail]> 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