Re: [Trans] OCSP and SCTs

[Brian Smith <[e-mail]>]

On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <[e-mail]> wrote:
> On Aug 30, 2014, at 15:43, Brian Smith <[e-mail]> wrote:
>> On Sat, Aug 30, 2014 at 3:22 PM, Fabrice <[e-mail]> wrote:
>>> On Aug 30, 2014, at 14:16, Brian Smith <[e-mail]> wrote:
>>>
>>> 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.
>>>
>> When the client is enforcing CT, it should reject the certificate due
>> to the missing SCT before it even attempts revocation checking.
>>
>> Thus, it would never fetch the OCSP response and so it would never
>> learn the SCT from a fetched response.
>
> I don't see any language in the RFC or draft that suggest there is an
> ordering between revocation checking and CT validation, or any other parts
> of the certificate validation. The only related language I found is rather
> succinct:
>
> In addition to normal validation of the certificate and its chain, they
> should validate the SCT (...)

I understand that your question is "If I fetched an OCSP response,
should I recognize the SCTs in the fetched response?" I don't have any
opinion on that.

You are right that the spec. doesn't talk about the ordering of doing
revocation checking and SCT processing during certificate chain
validation. I believe that the best ordering is to process SCTs, and
reject certificates without SCTs, before doing revocation checking or
path building, especially revocation checking and path building that
requires doing any networking (OCSP fetching and/or AIA chasing),
because this reduces the risks that are inherent in doing that
networking and with doing path building in general. The draft should
be changed to say that.

However, you agree that the current draft allows a client to reject a
certificate due to a missing SCT before it attempts any AIA chasing
and/or OCSP fetching, right? If so, then the server must provide the
SCT in the handshake--in the TLS extension, in the certificate, or in
a stapled OCSP response--to interoperate with clients that work that
way, regardless of whether some clients process SCTs in fetched OCSP
responses.

> If there are good reasons to ignore SCTs in non-stapled OCSP responses, I'd
> like to know about them, and it probably should be mentioned in the RFC.

A browser needs a reliable mechanism for getting SCTs in order for the
browser to be able to make SCTs mandatory. Browsers that make SCT
mandatory would ultimately be what would make CT effective. OCSP
fetching is not reliable, in theory or on practice, so a client cannot
rely on getting SCTs via OCSP fetching. A browser that processed SCTs
in fetched OCSP responses would be encouraging websites to avoid the
reliable mechanisms of SCT delivery in favor of an unreliable
mechanism, causing CT to be unreliable and thus ineffective.

Cheers,
Brian