On 6 February 2014 19:05, Adam Langley <[email protected]> wrote: > On Thu, Feb 6, 2014 at 1:51 PM, Rick Andrews <[email protected]> > 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.
Just to clarify: if CAs want to use OCSP stapling, then obviously they need to add CT support to their OCSP responder. But the only thing CAs really _have_ to do is the embedded case. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
