On Mon, Mar 23, 2026 at 8:13 AM John Mattsson <[email protected]> wrote:
> Hi Eric, > > Thanks for the clarification. I wanted to state that endpoint typically do > not do revocation checking. Correct me if I am wrong, but my understanding > is that browsers the revocation checking in browsers is often only partial > and with soft-fail. And I don’t consider soft-fail revocation checking to > be revocation checking at all. > Well, sort of. There are two main general mechanisms for providing revocation: - Use OCSP - Distribute a centrally managed revocation list Historically browsers used OCSP, but starting with Chrome, they have gradually moved towards centralized lists, and this is now common practice. Chrome [0] and Safari both use partial lists, whereas Firefox uses a complete list based on CRLite [1]. Chrome and Firefox hard fail on hits against the list and don't check OCSP at all. As I understand the situation with Safari (hopefully someone will correct me if I'm wrong) their system is built on Bloom filters and so they check OCSP on a Bloom filter hit but then soft fail. -Ekr [0] https://www.chromium.org/Home/chromium-security/crlsets/ [1] https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/?_gl=1*73mnwz*_ga*MTM3MDA3NjU1My4xNzYyMzgyNzQ1*_ga_X4N05QV93S*czE3NzQyNzc5OTMkbzI5JGcwJHQxNzc0Mjc3OTkzJGo2MCRsMCRoMA .. > (I really don’t want to imply that WebPKI and browsers are doing a bad > job. I think they are doing a great job for the Web use case. It is just > not very suitable for other sectors such as enterprise, government, > telecom, etc.) > > Cheers, > John Preuß Mattson > > *From: *Eric Rescorla <[email protected]> > *Date: *Monday, 23 March 2026 at 16:02 > *To: *John Mattsson <[email protected]> > *Cc: *Salz, Rich <[email protected]>, Tls <[email protected]>, [email protected] < > [email protected]> > *Subject: *Re: [lamps] Re: TLS Client Certificates; a survey > > > > On Mon, Mar 23, 2026 at 7:46 AM John Mattsson <john.mattsson= > [email protected]> wrote: > > Very unrelated from WebPKI, but almost all 3GPP use of TLS, DTLS, and QUIC > are mutually authenticated and will continue rely on TLS-Client > certificates. 3GPP relies on the Internet PKI profile (RFC 5280) for > everything including device certificates. I think the same applies to the > other large use cases of mTLS in enterprise, government, and IoT. > > I am worried about recent trends to use WebPKI for non-Web use cases. The > WebPKI relies on hundreds of trusted roots, have quite weak security for > issuance, does not do revocations, > > > This statement is not correct. The WebPKI does do revocations. In fact, > there are so many > revocations (about 8 million/1% of the issued number) that you need > special data structures > to efficiently propagate the revocations to the browser [0] > > -Ekr > > [0] > https://research.mozilla.org/files/2025/04/clubcards_for_the_webpki.pdf?_gl=1*11knujb*_ga*MTM3MDA3NjU1My4xNzYyMzgyNzQ1*_ga_X4N05QV93S*czE3NzQyNzc5OTMkbzI5JGcwJHQxNzc0Mjc3OTkzJGo2MCRsMCRoMA > .. > > and now will not do client authentication. It is very unsuitable for most > other use cases. Similarly, technologies and policies like transparency and > short-term certificates might not be adding much for other applications. > > Cheers, > John Preuß Mattsson > > *From: *Salz, Rich <[email protected]> > *Date: *Monday, 23 March 2026 at 15:36 > *To: *Tls <[email protected]>, [email protected] <[email protected]> > *Subject: *[TLS] TLS Client Certificates; a survey > > Since WebPKI CA’s will not be able to issue TLS-Client certificates, what > are the customers and CAs thinking of doing? > > Replies to be will be summarized to both lists. Please be careful if you > use reply-all. > > _______________________________________________ > Spasm mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
