Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Mar 2024 05:33:46 +0900
From: Valtteri Vuorikoski <>
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
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.


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.