Subject: [Trans] OCSP and SCTs

From: Fabrice <[email-masked]>
Date: Sat, 30 Aug 2014 13:48:44 -0700

Hi,

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?

Also, should 6962-bis also reference rfc6961 (multiple OCSP responses extension) in addition to rfc 6066?

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?

Thanks 

-- Fabrice

---

From: Brian Smith <[email-masked]>
Date: Sat, 30 Aug 2014 14:16:29 -0700

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

Cheers,
Brian

---

From: Fabrice <[email-masked]>
Date: Sat, 30 Aug 2014 15:22:00 -0700

> On Aug 30, 2014, at 14:16, Brian Smith <[email-masked]> 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.

-- Fabrice

---

From: Brian Smith <[email-masked]>
Date: Sat, 30 Aug 2014 15:43:17 -0700

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

Cheers,
Brian

---

From: Fabrice <[email-masked]>
Date: Sat, 30 Aug 2014 21:05:51 -0700

> On Aug 30, 2014, at 15:43, Brian Smith <[email-masked]> wrote:
> 

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

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.

---

From: Brian Smith <[email-masked]>
Date: Sun, 31 Aug 2014 11:44:10 -0700

On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <[email-masked]> 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 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:
>

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

---

From: Fabrice Gautier <[email-masked]>
Date: Sun, 31 Aug 2014 13:36:10 -0700

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

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.

---

From: Kyle Hamilton <[email-masked]>
Date: Sun, 31 Aug 2014 17:57:38 -0700

The more you apply your own "best idea" decision tree, the more you restrict perfectly valid options that would otherwise be legitimate by the spec, in the name of "interoperability". This is why, for example, Netscape's insistence on a "trustworthy" (which really devolves to "known, without judgment of trustworthiness") certifier managed to create a new and completely artificial cottage industry that suffered artificial stunted growth patterns... because it insisted on ITU-standard authentication before anyone knew what it was really good for.  It also basically destroyed one of the use-cases explicitly permitted by the spec, that of the unauthenticated connection.

Don't insist on a client-protocol stapling.  Not everything uses TLS -- and even though TLS is the intended use case, leaving low hanging fruit for other protocols is probably better than binding it so tightly to TLS that no one can conceive of a use aside from that binding.

-Kyle H

On August 31, 2014 11:44:10 AM PST, Brian Smith <[email-masked]> wrote:
>>>> To me, it seems logical for the TLS clients to process SCTs found
>in those
>>>> responses, no matter how it got them.
>>>>
>> In addition to normal validation of the certificate and its chain,
>they
>> should validate the SCT (...)
>
>_______________________________________________
>Trans mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/trans

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.