On Fri, Jul 05, 2024 at 02:59:36PM +0200, Clemens Lang wrote: > Hi, > > > On 5. Jul 2024, at 14:49, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote: > >> > >> > >> Please start addressing this with whoever maintains the TPM specification. > > > > The TPM spec is maintained by the Trusted Computing Group, and I have > > no influence there. > > You could try to bring it up with them, on a mailing list, for example. Have you tried? Would be lovely if they had a mailing list, or a place to file bugs, but AFAICT it is a closed industry members only group with no formal way to give feedback as an outsider. Perhaps could find someone at IBM who could do it on our behalf. In addition I've learnt that Windows 11 is still creating TPM based keys using a SHA-1 algorithm for something related to TPM key attestation :-( > >> SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this > >> change is already broken in FIPS mode, and the deprecation of SHA-1 will > >> only continue to cause more and more problems. > > > > swtpm works around that be unconditionally disabling FIPS mode in openssl > > already. > > > > This is fine, because the guest OS can put itself in FIPS mode, which > > will prevent it from using the undesirable algorithms, even if the TPM > > exposes them. > > No, this is a misconception. FIPS mode does not just disable algorithms, > it also enables additional selftests and code paths, and changes the > behavior of random number generators and key generation. > > If your guest OS is in FIPS mode and uses cryptography from swtpm, that > cryptography is still not FIPS compliant, and you should not misrepresent > it to be. In fact, we should probably add it to the list of packages that > do not use FIPS compliant cryptography in RHEL at [1, 2] if it isn’t on > there yet. It isn't listed there, but it certainly should be, as we've not been considering it FIPS compliant, for precisely this reason. > Please don’t make such decisions (for RHEL) without talking to > the crypto team. On Fedora, we don’t make any claims as to > FIPS-ness of the operating system, so it’s fine there, but > probably also not a great idea. FYI, disabling FIPS was done by the upstream maintainer, it isn't a downstream change. 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 :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
