Hacker News Reader

Comment by ak217 | Hacker News Reader

[Not OP]

CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale.

Revocation in PKI is a hard problem that exposes a fundamental tradeoff between time to revoke and privacy/offline capability.

View on HN

Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.

PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints).

There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.

That's a fair point [PKI without TLS], but I'd argue that 99.9% of situations will be with TLS. Thus supporting revocation can provide value for those.

Out of curiosity, what without-TLS use cases do you have in mind?

Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS.

Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit.

There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures.

And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.

Reply on news.ycombinator.com