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

[Rick Andrews <[e-mail]>]

> -----Original Message-----
> From: therightkey [mailto:[e-mail]] On Behalf Of
> Ben Laurie
> Sent: Saturday, February 08, 2014 5:40 AM
> To: Adam Langley
> Cc: [e-mail]; certificate-transparency; CABFPub
> Subject: Re: [therightkey] Updated Certificate Transparency + Extended
> Validation plan
> 
> On 6 February 2014 19:05, Adam Langley <[e-mail]> wrote:
> > 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.)

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