[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKLnGtQHn4SdNEDND-9g7TbF6A6SbpYbW4Z8Tsf9W4ssuDf71A@mail.gmail.com>
Date: Tue, 12 Mar 2024 09:23:26 -0400
From: Armin Kuster <akuster@...sta.com>
To: oss-security@...ts.openwall.com
Subject: Re: Certificate policy: OCSP becomes optional and CRLs
mandatory for public CAs on Friday
On Mon, Mar 11, 2024 at 4:35 PM Valtteri Vuorikoski <vuori@...com.org>
wrote:
> This is more of a meta-security
By "meta-security" do you mean the Yocto/OE meta layer by that name?
https://git.yoctoproject.org/meta-security
- Armin
> 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.
