[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <avwrjlt7heiiq64iy56v6raowqilc7ldg4ona2khtbfcl6n4mg@ay3mbinzz3fm>
Date: Wed, 13 Mar 2024 01:07:20 +0900
From: Valtteri Vuorikoski <vuori@...com.org>
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 12:28:49AM -0400, Demi Marie Obenour wrote:
> 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?
I have no idea whether this idea has been discussed by distros or
implementors of said libraries. Perhaps someone directly involved can
weigh in on this.
But on the face of it, CRLite-on-the-server sounds like a pretty good
idea for users who are fine with getting only a yes/no revocation
result (as opposed to the reason code and other details present in the
full CRL) and trusting the CRLite aggregator. Getting direct and
easy-to-deploy support in popular TLS libraries would seem like a net
positive for TLS security; needing to bring in a separate library, at
least if it's a relatively weighty one like NSS, probably wouldn't get
a lot of traction.
-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.
