FIPS provider backports

"No solution" implicitly would state "If you need to deploy something with a FIPS stamp, you need to deploy something that we know has a serious bug". Pretty much the opposite of what the FIPS certification means to assert and clearly unacceptable.

"Wait until a newer FIPS provider appears" seems like a tractable answer -- if a) accompanied by a definite timeline to availability/"certified status" and b) the assertion that it's not still subject to the same "serious bug" (which certification should assure of course).

You correctly point out that there is still "some time" before a validation -- and AFAIK that's pretty long (did I hear 2 years currently?) and indeterminate. So arguably something that needs to be worked around. This is further compounded by the need to maintain a last-known-certified FIPS branch, which arguably is somewhat wasteful given there are (most likely different, as you point out) active branches by the time the problem surfaces.

All this to me seems to call for the need to do 2 things:

1) Always have at least one "designated next FIPS" branch that is active/subject to backports (and obviously, CMVP testing) that always can be put to a FIPS certification lab immediately.

2) Ideally/optionally, come up with a way to work around the "certification timeline indeterminism", e.g. by creating a constant stream of FIPS providers, regularly scheduled (on both ends of the certification pipeline: Input of the "designated next FIPS branch" to the test lab and eventually final approval of that).

This surely is expensive but would allow the project a) to give a definite answer wrt to availability of a next FIPS provider and b) de-risk the deployment of FIPS modules (by hopefully having a more current version without the same vulnerability have come out of this pipeline sooner; but at least (and at latest) by a --roughly-- known date).

@Michael Baentsch Then the periodic government shutdown happens, and the whole schedule and contingency plan is thrown in disarray!

I am not sure OpenSSL can fix what is clearly a FIPS issue!

it is not new to anyone that NEEDs to use FIPS validated modules, that they will be running hardware or software that is years behind current development, improvements, and fixes.

We minimize the impact already by tightly defining the boundary of the FIPS module to only include the cryptographic implementations: usually that means that although you are running an older version of the cryptographic implementation, it was one that was blessed with the magic rubber stamp of FIPS validation. The track record seems to show that it is working well to avoid seriiis security defects within the FIPS boundary, and usually what tends to fail is the glueing with the outer OpenSSL layers, which means that you might not be able to use your FIPS validated modules with the latest and greatest protocol or transcoding supported by latest OpenSSL, but that is part of the burden that you take on operating in a context where FIPS-validation is required.

Outside of the FIPS-required markets, it is up to each organization to decide if they prefer running an old but stamped module or a recent module with all stable fixes and improvements.

Many users might be under the impression that FIPS-stamped means safer and better, but that might be in doubt when the stamping process is broken and cannot keep up with software and hardware development speeds in a reasonable way.

So what can OpenSSL really do about this?

I think it is already doing something like @Michael Baentsch proposed: they regularly send the latest and greatest FIPS module to the validation queue, somewhat regularly as last submissions seem to align with minimal delay with the time-based releases. That means there is an always cooking new version of the FIPS module in the barrels of the FIPS stamping cellar, but there is nothing OpenSSL (or any vendor really) can do to provide FIPS-stamped vintages that are not at leeast ~2-years-old once they are ready for consumption!

A two year wait while remaining vulnerable is not a good look.

Fortunately, NIST has processes that allow existing FIPS 140 validations to be updated without undertaking a full revalidation. These processes are much faster than the two or so years for a full validation.

Ideally, the project would fix all vulnerable versions and revalidate them, using these processes, on the relatively rare occasions that a vulnerability is discovered in the FIPS providers.

CMVP programme allows update submissions. Thus if desired one can submit an update.

On Ubuntu, there is Ubuntu provided FIPS module via Pro subscription that as far as I can tell is not affected. Use that maybe?

Separately if one is operating under FedRAMP there is a policy for operating update streams (assuming there is a CVE or bugs, one can switch to an update stream, until there is a new validated update). The update needs to be submitted within 6 months. Hence many vendors start to submit every 6 months. Or wait for a new submission to then apply identical fixes to the previous branch. This doesn't work for Common Criteria.

It would help to open a branch based on 3.1.2 tag, and cherrypick fixes that affect the boundary code. The ECDSA side channel, and this. So like 3 patches or however long it was.

You can fix bugs with a certificate update (which is much cheaper and faster to do than a full revalidation), you do not need to undergo a full revalidation, but of course that means patching the version that was validated not a completely new version.

For CVEs there is a specific security update process and for other updates a different one.

FIPS-140-2 certificates cannot be updated anymore after January (IIRC) as that program is well into EOL shutdown process.

For FIPS-140-3 certificates your Lab should be able to tell you what update process is best to follow (there are some issues with interim certificates though).

I suppose from a corporate policy/administrative standpoint, the easy solution would be to state that any openssl release which is FIPS validated is an LTS release, aligning the support lifetime with the FIPS certificate sunset date (roughly, if we assume LTS support periods account for the NIST validation time) - i.e. LTS support is extended to 5 years plus the ~18-24 months it took to from the time we released to the time we got the validation.

Additionally/alternatively, yes, we could (and I think aspire) to get to the point where every major release goes through an FSL validation, while every minor release gets an UPDT validation.

Neither of those address the current situation though, in that our only FIPS-140-3 certified module is out of its support window. 3.5.4 is currently in process (I think thats the right version). So perhaps if we commit to at least the LTS defintion change above, we can take it on the chin this one time, mea culpa it, and indicate that we will have a new FIPS validated provider soon-ish (I hope)?

Instead of the whole release being flagged as LTS, just the FIPS provider could be. This has been mentioned in several of the discussions along the way.

What we need here is a decision. While an OMC member, I repeated raised the supporting FIPS issue and it was never resolved. Several years later and it still hasn't. I know that there is a lot going on but this is something the communities need clarity over.

Each FIPS validated release for the FIPS validation itself is supported for the lifetime of the validation - in that we will fix FIPS specific security relevant issues. The release itself is not an LTS in general. This has been our practice since the 3.x FIPS validation series. Suggestions to also treat each release that received FIPS validation as an LTS were rejected as the LTS label has a very specific meaning and is independent of the FIPS validation status.

There are very specific challenges related to the "fast path" validations for dealing with CVEs which the program is still having challenges sorting out (in terms of impacts on usage of prior versions of the FIPS validated module which are handled differently once a CVE fix path is selected) and impacts on rebranded modules.

We are submitting releases for validations on a more regularly timeframe - but waiting in the review queue remains the longest part of the process currently. The most recent 3.5 based module is in review-pending status as of 8th October 2025 and I expect we will submit the next module for validation before that module reaches "In Review" status.

The particular issue noted is not a security issue - it was classified as a bug - and there is a work around for it that is trivial at noted in the discussion.