[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Mar 2024 05:33:46 +0900
From: Valtteri Vuorikoski <vuori@...com.org>
To: oss-security@...ts.openwall.com
Subject: Certificate policy: OCSP becomes optional and CRLs mandatory for
public CAs on Friday
This is more of a meta-security issue, but posting it since I expect
that this change will affect development priorities of
certificate and TLS-related OSS projects to some degree.
Last July, the CA/Browser Forum approved ballot SC-063
<https://cabforum.org/2023/07/14/ballot-sc-063-v4-make-ocsp-optional-require-crls-and-incentivize-automation/>.
The central changes to existing policy are:
* Makes providing OCSP services optional for CA/B-approved CAs,
i.e. those which ship in most browser and OS trust stores.
* Requires CAs to provide CRLs that are updated in a timely manner.
* (New policies related to short-lived certificates, not discussed
further in this post.)
The first two changes come into effect on 2024-03-15 which is this
Friday. CAs that provide OCSP services are free to continue doing so
under prior guidelines.
The proposal provides the following rationale for these changes (slightly
edited for brevity):
OCSP requests reveal details of individuals’ browsing history to the
operator of the OCSP responder. These can be exposed accidentally
(e.g., via data breach of logs) or intentionally (e.g., via
subpoena). Due to privacy concerns, several certificate consumer
products represented in the CA/Browser Forum do not perform online
OCSP checks by default - or have signaled interest in transitioning to
privacy-preserving methods of communicating revocation status. […]
Concern surrounding OCSP is further elevated considering the
disproportionately high cost of offering these services reliably at
the global scale of the Web PKI.
Given this ballot makes operating OCSP services optional
for CAs, allow relying party software applications and certificate
consumer user agents to consistently and reliably evaluate certificate
revocation status using a privacy-preserving check [using CRLs].
Personal opinion: It seems unlikely that most CAs will stop offering
OCSP now or even in the short-to-medium term. However OCSP support
(including OCSP stapling support) in open-source software has overall
been limited outside of HTTPS-related projects with a lot of developer
resources, and I suppose could have even less resources dedicated to
it in the future as a result of this change. Meanwhile some projects
may need to implement updates to handle large and relatively
rapidly-updating CRLs efficiently. In addition, I guess that OS level
mechanisms similar to root certificate stores may be needed to
centralize CRL updates; having each application pull down potentially
large CRL updates once a week seems inefficient.
-Valtteri
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
