(In reply to Ryan Sleevi from comment #7)
Recall that the original proposed mitigation is:
- For each precertificate issued according to our audit logs, verify that we are serving a corresponding OCSP response (if the precertificate is currently valid).
This is very reasonable, and it seems we disagree on whether the Precertificate should return something like 404, or "unknown" - both of which may be cached by clients and intermediaries without the ability to flush - or whether it's desirable to have the 'correct' response being served.
I agree that this is reasonable. My assumption here was that monitoring the audit logs for pre-certificates and verifying against OCSP is something typically done after step 6 completes (1-6 completes in ~1 second). I know that CAs do monitor audit logs to find and mitigate any issues in the process, including with pre-certificates. The assumption is absolutely that the verification using audit logs results in a proper ok/revoked response of that issuerDN/serialNumber. Correct me if I'm wrong, but the verification is not done within steps 1-6?
Attempting the scenario as you've described requires that the CA, whether Let's Encrypt or other, ensure that they can reliably evict such responses from caches. One way is to guarantee that the response cannot be cached; but that, of course, increases load on the CA. Thus, any increase in the cache time increases the risk that, by the time #6 happens (using your numbering), the certificate cannot be safely used / does not have a correct response.
We're still talking about the time gap of a few seconds right?
CT is entirely orthogonal to this. No one is proposing that CT be used to ensure clients can use OCSP efficiently. Rather, it's about understanding what commitments the CA is making when they log a precertificate. There are, for example, some CAs that delay generating an OCSP response until it's actually queried for (even for TLS cases), as a means of trying to reduce load on their signing servers; however, with CT, any client can monitor CT logs and query such certificates, thus defeating that load reduction.
I do not view not issuing a certificate, even though a pre-certificate was issued, to inherently be a bug. However, once a precertificate has been issued, all the necessary services for that response "should" be provisioned. This complexity is precisely why relying on Precertificates in OCSP is so fraught with peril; specifically, it requires the CA have a reliable mechanism to evict any caches that exist between them, the Subscriber, and the Client, as they transition from the "pre-precertificate" provisioned response to the "post-precertificate" provisioned response.
Thanks for this clarification. I had, perhaps erroneously, though that the "intent to issue" mandated by CT really meant "issue" and I know others have made the same interpretation. Meaning that if not enough SCTs are received the certificate MUST be issued anyhow, and preferably revoked as it can not be used. If this is not the case that can affect implementation quite some.
The more details such as this included in the process description the better, it gives CAs better understanding what is ok and not. Not actually issuing can be considered a short cut, allowed or not, but it may actually save from some obscure corner case errors.
Again, #3 in Comment #6, places significant burden on CAs with respect to monitoring if #6 is failing, which is why the flow in Comment #3 was my naive understanding. I would normally think CAs would want to reduce risk.
I'm not working for a CA, but I'm sure they want to reduce risk.
I am aware of real issues of pre-certificates existing without certificates, but I have not heard about problems with OCSP cache poisoning due to pre-certificate logging and OCSP requests occurring before the certificate was issued. That doesn't mean it doesn't happen of course, I would like to hear about such cases in order to learn.