Bugzilla

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.

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.

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.

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.

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.

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.

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.

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.