On 11/02/2023 02:13, Jacob Champion wrote:
> 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.
A-ha! I browsed around OpenSSL APIs and the source code, but missed
X509_get_signature_info(). Good find!
X509_get_signature_info() calls X509_check_purpose(), which calls
internal function ossl_x509v3_cache_extensions(), which extracts and
caches quite a lot of information from the certificate. It calculates
and caches its SHA1 hash, for example. That seems acceptable, the
overhead is negligible and I don't see any scenario where
X509_get_signature_nid() would succeed but X509_get_signature_info()
would fail.
+1 on your patch. I think the only thing it's missing is changes in
meson.build and Solution.pm to match the configure.ac changes.
> 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.)
Agreed, if we have an easy solution for RSA-PSS, that's good enough for now.
> <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>
Fair points.
- Heikki
