[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ze_aAzVya8RMGDDZ@itl-email>
Date: Tue, 12 Mar 2024 00:28:49 -0400
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Subject: Re: Certificate policy: OCSP becomes optional and
CRLs mandatory for public CAs on Friday
On Tue, Mar 12, 2024 at 05:33:46AM +0900, Valtteri Vuorikoski wrote:
> 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.
macOS, iOS, Windows, and possibly Android have system certificate
verifiers that can handle this easily. For desktop and server Linux,
should a CRLite package be included in system package managers? Would
it be feasible for WebPKI and {Open,Boring,Libre}SSL to handle CRLite,
or does this mean that NSS should be used for certificate verification?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
