Re: [Trans] OCSP and SCTs

[Fabrice <[e-mail]>]

> On Aug 30, 2014, at 14:16, Brian Smith <[e-mail]> wrote:
> 
>> On Sat, Aug 30, 2014 at 1:48 PM, Fabrice <[e-mail]> wrote:
>> Regarding the transport of SCTs as part of OCSP responses, the RFCs only talk about it in the context of OCSP stapling. Can SCTs also be provided in non stapled OCSP responses to TLS clients?
> 
> A client that requires SCTs cannot rely on an unreliable fetching
> mechanism like OCSP fetching to get the SCTs. Consequently, the web
> server must always give the client the SCTs so that the client doesn't
> have to fetch anything to get them.
> 
>> Or should the language be generalized to just talk about SCTs in OCSP responses, no matter how those responses are provided to the TLS client?
> 
> No. It is critical that the OCSP response be stapled if the SCTs are
> embedded in an OCSP response.
> 
> Just one example why: Imagine a captive portal on a Wifi network that
> forces people to login at https://example.org/ and which blocks
> requests to the OCSP responder for its certificate. If the SCTs are
> not provided in the handshake (in the certificate, in the TLS
> extension, or in a stapled OCSP response), then there would be no way
> to get the SCTs.

I understand the issue you describe and how stapling has less opportunities for failures and is a MUST for TLS clients, but my question was really about what should a TLS client do when it does not get an OCSP response through stapling (RFC6066) but get one directly from the OCSP responder or potentially other means. 

To me, it seems logical for the TLS clients to process SCTs found in those responses, no matter how it got them.

-- Fabrice

> 
> Cheers,
> Brian