[lamps] Re: TLS Client Certificates; a survey

[Nico Williams <[e-mail]>]

On Tue, Mar 24, 2026 at 09:25:42AM +1300, Alan DeKok wrote:
> On Mar 24, 2026, at 8:18 AM, Jeffrey Walton <[e-mail]> 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
--