On Thu, Oct 16, 2025 at 10:41:47AM -0500, Eric Blake wrote: > On Fri, Sep 19, 2025 at 11:10:20AM +0100, Daniel P. Berrangé wrote: > > This usage flag was deprecated by RFC8813, such that it is > > forbidden to be present for certs using ECDSA/ECDH algorithms, > > and in TLS 1.3 is conceptually obsolete. > > > > As such many valid certs will no longer have this key usage > > flag set, and QEMU should not be rejecting them, as this > > prevents use of otherwise valid & desirable algorithms. > > > > Signed-off-by: Daniel P. Berrangé <[email protected]> > > --- > > crypto/tlscredsx509.c | 10 +------- > > docs/system/tls.rst | 13 +++------- > > tests/unit/crypto-tls-x509-helpers.h | 6 ++--- > > tests/unit/test-crypto-tlscredsx509.c | 36 +++++++++++++-------------- > > tests/unit/test-crypto-tlssession.c | 14 +++++------ > > tests/unit/test-io-channel-tls.c | 4 +-- > > 6 files changed, 34 insertions(+), 49 deletions(-) > > My understanding is that the reason you coded all the sanity checks > into qemu was to provide saner error messages for users that create > invalid keys than what gnutls does (keys are already hard enough to > create securely, so it is nice to be told how to fix your key rather > than just "it didn't work"). I also understand that newer algorithms > really can't use this flag, and we don't want to reject use of better > algorithms, so this patch makes sense as documented.
Yes, admin configuration mistakes with TLS certs are an incredibly common problem, frustratingly hard to diagnose, especially when the failure only happens at runtime, not startup. So this code is mostly about "sanity checks" on configuration. > Still, is there any risk that for older algorithms, where the 'key > encipherment' bit did matter, that we could now end up processing an > incomplete key that we would have previously rejected with a nice > message but which now goes to gnutls and reverts back to the poorer > error message quality or even worse being used despite being a > security risk? I don't think it is a high risk - fewer people would > be generating certificates that explicitly request an older algorithm > but not following all the recommended steps, compared to the more > common case of people following your documentation and getting the > newest defaults that just work; anyone determined enough to get an > older algorithm deserves the breakage if their explicit instructions > to override the default are weaker than normal. Yes, it is a slight degradation in the checks we are doing in certain scenarios. As the world moves increasingly towards eliptic curves and/or post-quantum crypto, the check is less and less important. So its an acceptable tradeoff. I've got another series coming soon that supports post-quantum crypto better in QEMU > In saying that, I'm hoping that gnutls still diagnoses certs that > cannot be properly used for the purpose at hand (whether or not the > 'key encipherment' bit must be set or cleared), even if it gives a > less-than-stellar diagnostic message about rejecting a cert. If I'm > wrong, and an incomplete cert with an older algorithm but missing the > bit turns into a security bypass, it's much more than QEMU that would > be impacted. So, I'm comfortable with: > > Reviewed-by: Eric Blake <[email protected]> With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
