[lamps] Re: TLS Client Certificates; a survey

[Eric Rescorla <[e-mail]>]

On Mon, Mar 23, 2026 at 8:13 AM John Mattsson <[e-mail]>
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 <[e-mail]>
> *Date: *Monday, 23 March 2026 at 16:02
> *To: *John Mattsson <[e-mail]>
> *Cc: *Salz, Rich <[e-mail]>, Tls <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [lamps] Re: TLS Client Certificates; a survey
>
>
>
> On Mon, Mar 23, 2026 at 7:46 AM John Mattsson <john.mattsson=
> [e-mail]> 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 <rsalz=[e-mail]>
> *Date: *Monday, 23 March 2026 at 15:36
> *To: *Tls <[e-mail]>, [e-mail] <[e-mail]>
> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>