On Thu, Feb 9, 2023 at 2:46 PM Michael Paquier <michael@paquier.xyz> wrote:
> I could get that some users would want to be able to use such certs,
> though. At least we have one such user as of this thread.
My take on this bug is that Gunnar doesn't need to solve the general
"undef" case. They've got a certificate that's supposed to be using
SHA512.
It looks like OpenSSL 1.1.1 gives us a better API for grabbing that;
see attached draft (not mesonified, needs independent verification),
which fixes Heikki's certificate case at least. It's unfortunate that
it doesn't reach back to 1.0.2, or to LibreSSL, but that doesn't
appear to be a problem for Gunnar's situation, and you'd mentioned
wanting to drop 1.0.2 support in HEAD soon anyway.
Maybe someone really wants to use EdDSA certs, which aren't handled by
that API. But this stopgap would buy us some time for the
cryptographers to settle on things -- or at least to ask them? And if
people want new crypto they're going to need to upgrade eventually.
(Maybe by that point we'll know that X509_digest_sig() is in fact
correct for bindings.)
<strong opinions>
- Our current departures from the spec (e.g. no tls-unique) mean that
we already can't interoperate with standard SASL libraries. I've been
trying to realign them, slowly.
- Coming up with our own binding type takes time and resources away
from other things this thread highlighted (the ability to force the
use of a binding at the server side. better behavior when we can't
actually compute a binding value. tls-exporter support...).
- Worst case, using SHA256 for a future certificate type might be
*catastrophically* wrong, but no one's going to warn us, and it's not
going to be obvious to the DBA or their users that our nonstandard
binding is in effect.
- Best case, we choose exactly right, but if/when tls-server-end-point
gets updated for EdDSA, the world will move on and we'll still have to
support that vestigial binding type for the next X years.
</strong opinions>
--Jacob
