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
