[er4hn]

The biggest problem with JWTs is not what cryptography you use (though there was a long standing issue where "none" was something that clients could enter as a client side attack...) but rather revocation.

x509 certificates have several revocation mechanisms since having something being marked as "do not use" before the end of its lifetime is well understood. JWTs are not quite there.

[codebje]

JWT is just a container for authenticated data. it's comparable to the ASN.1 encoding of an x509 certificate, not to the entire x509 public key infrastructure.

You could compare x509 with revocation to something like oauth with JWT access tokens, though.

In that case, x509 certificates are typically expensive to renew and have lifetimes measured in years. Revocation involves clients checking a revocation service. JWT access tokens are cheap to renew and have lifetimes measured in minutes. Revocation involves denying a refresh token when the access token needs renewing. Clients can also choose to renew access tokens much more frequently if a 'revocation server' experience is desirable.

Given the spotty history of CRLDP reliability, I think oauth+JWT are doing very well in comparison. I'm pretty damn confident that when I revoke an application in Google or similar it will lose access very quickly.

[tialaramex]

> x509 certificates are typically expensive to renew and have lifetimes measured in years

In the Web PKI thanks to Certificate Transparency we can measure, the typical X509 certificate was issued by ISRG (Let's Encrypt) and thus cost well under one dollar (free to the subscriber, that cost is borne by the donors) and has a lifetime of precisely 90 days.

[codebje]

> In the Web PKI thanks to Certificate Transparency we can measure, the typical X509 certificate was issued by ISRG (Let's Encrypt) and thus cost well under one dollar (free to the subscriber, that cost is borne by the donors) and has a lifetime of precisely 90 days.

Yes, it's true that in the past few years Let's Encrypt has substantially altered the typical lifetime of web server certificates, as well as substantially eased the burden of refreshing a certificate in what I would guess to be the majority of use cases.

Revocation, however, is still a mess. OCSP services are slow and a privacy leak, and are largely ignored by browsers - in 2021 Firefox was still checking OCSP services but given they're so unreliable if it can't contact a service it assumes the certificate is fine. OCSP winds up being a trade-off between allowing an attacker to conduct a denial of service on all certificates or blocking revocations.

In practice the major browser vendors all do more or less the same thing - build their own proprietary list of revoked certificates and distribute it to browsers from time to time, with varying sources and granularity on what they will and won't include in their centralised CRLs. I would have little faith in a timely revocation of a compromised server certificate.

[Sirened]

Not to mention OCSP stapling provides a revocation escape hatch that allows a certificate to continue to be used even after it has been revoked and the revocation has been streamed to all relevant OCSP servers.