Why?
If there's nothing being signed, there's nothing to log for any audit? But if there's any OCSP response signed, then it needs to be logged for auditing.
In theory, LE can simply provide an empty document with "Signing of OCSP Responses" and say: "Here are the records of all signed OCSP Responses, i.e., none."
Works for me! But I'm still ticked off by “The CA SHALL record at least the following events” verbiage…
Not sure why that matters? If the CA signs OCSP responses, it might log all the details in the world or omit some of the details, as long as at least those mentioned are recorded.. Now, English isn't my first language, but I personally don't see why "at least" changes anything from the fact there's nothing to log if there's no OCSP responses being signed.
Hi folks. This thread is great, but this particular detail is not up for debate. It is acceptable, per all root program requirements, the baseline requirements, and the webtrust audit criteria, for a CA to shut down their OCSP service as long as they are operating a compliant CRL service instead. This is true both in the letter and the spirit of the requirements, as made very clear by Ballot Sc-063v4, which went into effect in 2023 and has not been rescinded or overridden by any ballot since.
And to be clear: the requirement that CAs record "at least the following events" means that they may (and we do!) audit log other kinds of events as well, above and beyond the required kinds of events. It does not mean that they must fabricate OCSP signing records when no such events have occurred. For a demonstration of this, note that the BRs use the same language regarding recording of OCSP events for both CA certificates and Subscriber certificates, yet Let's Encrypt has not issued OCSP responses for CA certificates for several years now.
That's fine, although I still find value in the discussion. We get that CAs are allowed to do it, it just clearly has some impacts on the community that I think are worthy of discussion, which can also be valuable for other CA communities reading this if they are considering ending OCSP support.
(If it wasn't for short-lived 6-day certs I'd also be very actively participating in the discussion / resisting the ending of OCSP support, since implementing CRLs server-side to accomplish the same thing OCSP stapling does is quite much more tedious/expensive than OCSP stapling was.)
"at least" means you are allowed to do more, but you are not allowed to do less.
On the other hand, at page 72, section 4.10.2 on service availability, the same baseline requirements state that OCSP is optional, which agrees with the 2023 ballot, so if I were the auditor I would pass it as compliant.
According to Policy and Legal Repository - Let's Encrypt, the last audit dates back to 20/11/2024. LE's decision to end OCSP support is dated 5/12/2024. The decision was made after the audit, which is most unfortunate.
Note that the date of our decision doesn't matter; audits cover current actual practice, not hypothetical future practice. We made this decision long before we announced it, but that doesn't affect our past audits.
Please see my edit above regarding the audit criteria. There is clear historical precedent that it is acceptable to have recorded zero OCSP events as long as there truly were zero OCSP events.
Note that the date of our decision doesn't matter; audits cover current actual practice, not hypothetical future practice. We made this decision long before we announced it, but that doesn't affect our past audits.
The date of the decision does matter, both because it happened after the last audit and it precedes the actual operations, those that are unfolding as we speak. The audit is not up-to-date.
Please see my edit above regarding the audit criteria. There is clear historical precedent that it is acceptable to have recorded zero OCSP events as long as there truly were zero OCSP events.
Since you are the first CA to deprecate OCSP, there is no such historical evidence.
In your edit above, I read the following:
It is acceptable, per all root program requirements, the baseline requirements, and the webtrust audit criteria, for a CA to shut down their OCSP service as long as they are operating a compliant CRL service instead. This is true both in the letter and the spirit of the requirements, as made very clear by Ballot Sc-063v4, which went into effect in 2023 and has not been rescinded or overridden by any ballot since.
This is not historical evidence. What you did is to cite the ballot.
It looks compliant to me, but I am not your auditor.
My understanding is the audit is a point in time assessment of compliance, which is valid for one year. As such, LE is in full compliance with auditing requirements.
However. That does not mean issues can only be raised by an auditors. Non-compliance with the baseline requirements can and should be raised on Bugzilla. LE like most other CAs, periodically has issues raised, issues a post-mortem, and corrects them.
In this case the Baseline requirements are clear and unambiguous
An audit is valid at the time of issue, based upon the available evidence. It does not give you a licence to kill compliance for the next 12 months. If you brake compliance, and it shows up in the record of your operations, the next audit will fail.
I'm not sure what the point of discussion here is.
Let's Encrypt has made their opinions clear. If you feel strongly that OCSP is required by the baseline requirements and auditing requirements are being violated, you are free to take it up with the CA/B forum.
Let's Encrypt is a free service. You are free to use any CA you deem fit.
Opinions are no substitute for certified compliance.
in that case, I recommend you take your concerns to the CA/B forum which governs all Certificate Authorities.
If you are correct, I am sure they will require a prompt resolution
I believe the correct place to submit your concern is the CA Compliance area of Bugzilla
I think there is great value in discussion of whether CAs should discontinue OCSP support, what impact that has on the WebPKI community, and what others can do to adapt. I think there is less value in discussion (at least in this venue) of whether CAs can discontinue OCSP support, as that has already been settled at the CABF.
Apologies, we either seem to be speaking past each other, or there seems to be some fundamental misunderstanding of how audits work. You're correct that the most recent audit does not cover today's practices, as the last annual audit period ended in late 2024. However, even if the audit somehow went through today, it still wouldn't show what you're looking for, since we are still operating an OCSP service. The audit doesn't care that we've decided to terminate that service. The audit period ending later this year will cover time in which we are operating no OCSP service.
That is not the relevant quote. The relevant quote was:
Let's Encrypt only reports the revocation status of our issuing intermediates ("Subordinate CA Certificates") via CRLs, not OCSP. There have been no OCSP signing events for our CA certificates for many years. Yet our audits have never found us to be in violation of the requirement that we record all OCSP signing events for our CA certificates. This is because we do record all such events: all zero of them. The same will hold for OCSP signing events for subscriber certificates after we discontinue our OCSP service.
Regardless, as I said above, I think that discussion around what CAs should do, and what the rest of the community should do, is good and healthy, and I encourage it to continue here. If you truly believe that LE will be violating one of the requirements by discontinuing this service, please bring it up in Bugzilla, on dev-security-policy@mozilla.org, or on the cabforum public mailing list.