On Tue, Mar 24, 2026 at 09:25:42AM +1300, Alan DeKok wrote: > On Mar 24, 2026, at 8:18 AM, Jeffrey Walton <[email protected]> wrote: > > And who needs a CA anyways? All we need is a hostname and a public > > key. We don't need a CA to bind them. The hostname and public key > > information is presented in an end-entity certificate, so that's all > > we need. The self-signed certificate can be hosted in DNS and > > retrieved as required since that seems to be the modern equivalent > > to the X.500 directory. The world does not need to be adverse to > > self-signed certificates just because the CA/BF does not care for > > them.
That's DANE (when the entity to be authenticated is the server) / DANCE (when it's the client). > I find it a bit surprising that certificates can carry a substantial > amount of information about purposes, authorization, hierarchies, > etc. But that pretty much the only way to make them usable is to > just ignore all of that. Eh, that's unrelated to the above. The reason for what you say is that we're only a few months into the part of the LLM revolution where the LLMs become useful enough that lack of ASN.1 tooling is no longer an issue. Certificates are elegant and can carry tons of useful information, but for the past 30+ years it's not been feasible to rely on being able to extract that information. That's going to change soon. E.g., I've been working occasionally now on making massive enhancements to Heimdal's ASN.1 compiler and adding support for Java, but then after than adding support for all the languages will be pretty mechanical. I might even look at having it generate the C types and templates that OpenSSL uses. This compiler can decode through all the certificate extensions and what not in one shot. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
