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 protected]> wrote:
>On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <[email protected]>
>wrote:
>> On Aug 30, 2014, at 15:43, Brian Smith <[email protected]> wrote:
>>> On Sat, Aug 30, 2014 at 3:22 PM, Fabrice <[email protected]>
>wrote:
>>>> On Aug 30, 2014, at 14:16, Brian Smith <[email protected]>
>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
>
>_______________________________________________
>Trans mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/trans
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
