> -----Original Message----- > From: therightkey [mailto:therightkey-boun...@ietf.org] On Behalf Of > Ben Laurie > Sent: Saturday, February 08, 2014 5:40 AM > To: Adam Langley > Cc: therightkey@ietf.org; certificate-transparency; CABFPub > Subject: Re: [therightkey] Updated Certificate Transparency + Extended > Validation plan > > On 6 February 2014 19:05, Adam Langley <a...@chromium.org> wrote: > > 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.)
I thought the TLS extension will be sent only if the client requests it. 'Clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data".' And I suspect that CAs would need/want to create a service to help their customers obtain SCTs if they choose the TLS extension option. -Rick _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
