In a nut shell: the 3.0.0 FIPS provider is designed to work with all 3.0.x releases. We actively test this as part of our CI loops and it's the way to claim FIPS compliance when using OpenSSL 3.0.7. You need to build 3.0.7 (with or without FIPS support) and the 3.0.0 FIPS provider (as per the security policy instructions) and then use the 3.0.0 FIPS provider with 3.0.7.
It is true that there have been fixes inside the FIPS boundary. The project needs to individually assess each (well our validation lab has to). Not all of these fixes are security relevant, not all are relevant to the validated code but some are. The kind of change and its impact determine the method we use to update the validation (1-sub or 3-sub). We do plan on updating the validated version from time to time but it takes effort which has to be diverted from other tasks and FIPS changes tend towards glacial movement rates at the best of times. It simply isn't practical to update the validation with every release.
There is a fast track available for severe CVEs and we would utilise this if required. Currently, we are not aware of any bugs that would justify such treatment. As far as I remember, they are either theoretical, difficult to trigger or out of scope.
Pauli
On 23/11/22 12:12, Thomas Dwyer III
wrote:
The OpenSSL project has obtained certificate #4282 from NIST for the FIPS provider. Nice. However, the certificate and accompanying security policy specifically list version 3.0.0 while the current release is 3.0.7. There have been CVEs & bugfixes since the 3.0.0 release but it's not clear whether any of those directly affected the FIPS provider. Can someone from the OpenSSL project comment on the viability/suitability of using the 3.0.0 FIPS provider with a 3.0.7 libcrypto/libssl?
Thanks,Tom.III
