Hello. So, it is as if by magic that the x86_64 architecture is the lucky one chosen to support the cryptographic modules selected as candidates for the FIPS 140-3 certification submitted to the CMVP. Has the ARM architecture failed to sufficiently demonstrate its superiority in comparison, to make it the only relevant choice? Only time will reveal whether the decision at the time was wise.
Additional information beyond the corresponding announcement may be necessary to properly understand the validation context.
Is it the 9 product family or a sub-version of 9, of Rocky Linux, that is the subject of each cryptographic module validation?
Knowing that historically, and regardless of the FIPS 140 revision targeted by the submitter, the validation security level of a software cryptographic module has invariably been 1, it is reasonable to assume that this is the one targeted by the certification. But what is the official status?
Hopefully, the certificate attestation will soon be published –hopefully enough before the release of version 10, which is due in June 2027. But until then, one unknown remains; which of Rocky Enterprise Software Foundation and CIQ, Inc. is declared as the vendor of each of the cryptographic modules? May we know this, as it has relevance to the legal part?
This is a question to ask CIQ and the auditors why this was done. We (the project) had no part in the FIPS validation process.
It is locked to a specific version of Rocky Linux 9. What that version is, I do not know, but I do know that it’s unsupported from a project perspective.
The RESF took no part in the certification process, and thus, it is not owned by the foundation nor the project. There were talks about bringing the modules into a Special Interest Group, but that conversation has not yet been restarted as at the time, there were multiple questions and concerns from my team (Release Engineering) and our security team as it pertains to both the modules and the binary packages. Until those unknowns and questions are answered, it remains unclear what will happen with the modules and packages.
Thanks. As the founder of Rocky Linux and founder and CEO of Ctrl IQ (a.k.a. CIQ), Gregory M. Kurtzer was certainly no stranger to the decision to select the said architecture for FIPS validation. It should be assumed that this decision does not conflict with RESF’s interests in this matter.
Given the significant cost of FIPS validation, which increases with the quality level (1–4; the first two apply to the software) defined for it, the return on investment is of the utmost importance for Ctrl IQ, not to mention the engineering effort on the RESF side, which, if measured in monetary terms, would also be substantial.
Who, then, could be surprised that the code for the FIPS components integrated into the specific—as yet unannounced—and therefore unique version of Rocky Linux/Rocky Linux from CIQ (RLC)—which includes service level objectives (SLOs)—is solely hosted on the Ctrl IQ GitHub repository?
What should we conclude from the announcement made on that repository regarding FIPS-compliant security updates to post-validation cryptographic modules? Are they intended to only have an effect on the Rocky Linux from CIQ variant?
P.S.
Did I read the release announcement correctly? Here it is, Rocky Linux 10.0, the first version of the 10-family. Who knows if a specific version of it will one day receive FIPS certification? When I think about it, though, what a money machine this FIPS certification institution is.