Open bradfitz opened 8 months ago
This seems like something that would likely be useful in general for people writing Config.GetCertificate
functions.
We kind of have an inverse version of this already with ClientHelloInfo.SupportsCertificate
, but that requires you already have a certificate to test against, which is obviously not the case in this case and the autocert case (hence why it had to be written in the first place).
I'd not be opposed to adding the following method in crypto/tls:
// SupportsECDSA returns true if the ClientHelloInfo indicates the the client supports both ECDSA based
// key exchanges and cipher suites.
func (*ClientHelloInfo) SupportsECDSA() bool
cc @FiloSottile
Proposal Details
I recently found myself needing x/crypto/acme/autocert's
func supportsECDSA
but it's not exported.Copy/pasting it works, but is slightly sad as it's kinda long and I worry about it getting out of sync.
It's possible to use it indirectly via ugly hacks like https://github.com/tailscale/scertec/pull/3 (using a fake acme/autocert.Cache that looks which keys are accessed) but it's a bit too ugly.
Proposal: export that code somewhere? method on ClientHelloInfo even?
/cc @rolandshoemaker