> 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 (...) 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. > > Cheers, > Brian
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
