OQS as a (FIPS) cryptographic module?

[baentsch]

Triggered by open-quantum-safe/liboqs#2032 (comment) this is to raise the question whether some OQS sub projects (or sub components in sub projects) shall aim for the designation as a "cryptographic module".

A positive decision on this topic would put to rest many open questions, like #1, open-quantum-safe/oqs-provider#483, PQCA/TAC#44 -- with a clear-cut (sub)set of code subject to this designation and clear-cut quality goals to achieve.

It is apparent (in my experience, even completely clear), though, that such decision would require substantially more commitment and expenditure, e.g., for external certification labs, than OQS currently is able to muster. It also would be a 180 degree turn of direction of a project run by researchers for researchers and as such unlikely to be successful in such quest without markedly more support by commercial entities such as those comprising PQCA.

A negative decision on this topic could help OQS re-gain focus, back to furthering the state of the art and away from trying to compete with more mature FOSS and commercial PQC projects.

[dstebila]

As with our other discussions around direction of the project, I would say that this is not a direction we can actively move in with the current size of the contributor community. If there are commercial entities who would benefit from this direction, they'd need to take the lead on that.

[ashman-p]

Given that the pursuit of FIPS, or other certification, is a huge time and cost sync, I think it would not be a productive action of OQS to pursue. That being said, having implementations that facilitate such testing is very doable. IOW having APIs that allows access to test points and intermediate results would be very helpful.

So, I agree with Douglas and Micheal but, I also think there shouldn't be barriers in the design to such tests.

[baentsch]

Thanks very much for your take @dstebila @ashman-p !

I then see one immediate consequence, particularly per

there shouldn't be barriers in the design to such tests

Should we (or someone more suitable) approach NIST with a request for clarification on https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs#Rdc7 along the lines of: "Does this answer also apply to software-only implementations not qualifying as a cryptographic module? In particular, can the seed format be generally (freely, without restrictions) made available via API calls or data exports? If restrictions should be applied, which ones?"?

--> This would inform the OQS API design (or not, if either NIST answers with "No" or OQS finds no-one willing to commit to long-term support of "non-NIST competition algorithms' APIs").

The second thought is this: Would it make sense to apply this logic to balance OQS back to prioritizing research utility over commercial utility? New algorithm candidates support over tracking/catering for "more downstream", algorithm-specific standards?

--> One approach might be to require at least one, better two, non-research persons willing to commit to work him/herself into the position of an active, reliable contributor and ultimately, maintainer (I'd say at least as active as UWaterloo or myself) -- with the initial task to ensure proper design and integration of open-quantum-safe/liboqs#2032?