New answers tagged

0

I also agree with Steffen Ulrich, but I could see it from Microsoft's perspective. And no, I don't work for Microsoft nor asked any of their employees. Suppose an attacker can be MitM. Possible attacks? Via HTTP: tha attacker can replay an old CRL and have the victim think that the certificate is still valid. The victim won't notice the differrence and ...


9

I generally agree with Steffen Ulrich, I just want to add few cents, since OP references my own answer which I consider proper and valid. However OSCP responses are also signed by a revocable entity it's not a revocable entity. OCSP Signing certificates include id-pkix-ocsp-nocheck certificate extension that instructs clients to not check this particular ...


0

TLS/HTTPS clients do normally cache the results of OCSP/CRL requests. When a client sends a request to CA and establishes an HTTPS connection, most of the time it uses cached result of certificate validation. That's why no recursion occurs, no chicken-egg problem. Of course the client should consider the cases when cache result is not available or expired ...


7

... chicken-and-egg problem ... There is no real chicken-and-egg problem. Revocation (no matter if CRL or OCSP or something else) is only one part of the certificate validation, and it can still be better to do 95% (i.e. HTTPS w/o revocation check) than doing 0% (plain HTTP). ... don't provide replay protection ... you cannot reliably issue an emergency ...


Top 50 recent answers are included