Questions re: 2020.12.22 Failure to audit log subscriber certificate OCSP updates

[petercooperjr]

2020.12.22 Failure to audit log subscriber certificate OCSP updates

D…

This incident report confuses me, probably since I'm just a "layperson" and not intimately familiar with the bazillion audit requirements CAs have or all the terminology involved. (And I do understand that it has to be hard to try to write up an incident report that's comprehensive about the problem and yet understandable to everyone.) The way it reads to me, you're properly logging when certificate are available and have OCSP information, and properly logging when a certificate's status changes to revoked, but there are some other "subsequent updates" to OCSP that aren't logged (but need to be for the auditors). But I thought that the whole thing OCSP did was just tell you if a certificate was revoked or not, so I don't understand what these other "subsequent updates" are. Could you give some examples? Maybe some rough "timeline of a typical certificate" describing what changes are getting logged and which ones aren't? Or is it so esoteric and technical that I probably shouldn't ask since the answer will just confuse me more?

I'm also a bit confused on the severity of the issue. While I do understand that it's important for auditors to be able to verify that Let's Encrypt is certifying domains and telling people the correct status of the certificates, I also kind of feel that if it was missed for this long (and presumably missed in past audits?) that this requirement can't be too critical in terms of ensuring that the whole WebPKI is being protected, right? And this is just that dotting all the i's and crossing all the t's is the bread-and-butter of how a CA ticks, so missing this requirement is something that needs to be addressed, but that users aren't really in any danger of being deceived about certificate statuses, right? Or since the logging is missing is it that we don't really know?

Thanks for indulging my questions during a time that you're all way too busy with a bunch of other priorities too. I'm just overly curious, I guess.

[andygabby]

Great questions!

We are required to sign a new OCSP response for each certificate that is not expired or revoked about every 3.5 days, essentially to say “this certificate is still good”. This OCSP response is signed by our intermediate key(s). As you can imagine, this is a lot of traffic on our back end that most folks don’t even realize that Let’s Encrypt has to process. OCSP signing accounts for far more signatures per day than certificates that we sign.

Because this process is performing a signing operation from one of our trusted keys, the baseline requirements have a requirement that a signing operation for an OCSP response is logged and retained for a number of years (2 years as of recent changes). In this case there was a signing operation that didn’t get logged and stored.

There really isn’t any impact to subscribers or relying parties for an issue like this. OCSP status was correct for all certificates throughout their lifetimes.

We have disclosed the violation publicly per root program expectations and hopefully that record or any remediations can help us provide a better service, and other CAs may see it and find or avoid similar issues. Quite often a disclosure from one CA can help others realize they have the same problem and fix it.

I feel that the severity is fairly low for something like this, but that determination ultimately resides with each root program. It is best to be transparent and open to feedback which helps the root programs to help us provide a high level of trust to folks on the internet that rely on CAs and browsers to secure the internet.