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. 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. 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]> -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
