Re: [Trans] OCSP and SCTs

[Fabrice Gautier <[e-mail]>]

> On Aug 31, 2014, at 11:44, Brian Smith <[e-mail]> wrote:
> 
>> 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?

Yes, but only because I don't think the draft says anything about rejecting certificates without SCTs. It only says that the SCTs should be validated and defines what a valid SCT is.

The only document I know of that talk about how a TLS client would react to no SCTs (or not enough of them) is Chrome's published plans for tying together EV certs and CT. In that case, certificates are not rejected, just the UI would look different.

But I guess these are policy decisions that maybe out of the scope of the current draft.


> 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.

True,

Maybe the draft should specify that clients should not consider SCTs coming from unreliable mechanisms.

I think this might be an important detail for implementations which may not always know the origin of an ocsp response when processing it.


> Cheers,
> Brian