> > +The hash currently used is SHA256, though this
> > +could change in the future.
> 
> So ahh - this is a little bit bonkers. How would we ever practically change this, once software
> starts using this stuff.

Not my text/idea...

The text matches what the manpage for the tls_peer_cert_hash() API says.
I have no idea what the plan was if sha256 is effectively broken. I guess
you'd flip to a non-broken hash, crank the libtls API version define and
make a big fat warning in the release notes, perhaps add an _insecure_
version if someone needs that for backwards compat reason.

> IMO it would make a little more sense to just put sha256 in the name of this and outright say
> it is sha256 

So you also want tls_peer_cert_hash_sha256()? I dunno. Seems counter to
the sane defaults approach that libtls otherwise has.

> If we ever decide that we have to support needless sha3 bullshit, or defend against a kardeshev-3
> civilization, we can just add a separate API. 
> 
> So, my two cents - tls_peer_cert_pubkey_sha256, etc. or something like that. 

and a _hex or _base64 suffix to indicate what it spits out?