Roadmap

[dstebila]

With the release of the NIST standards, it seems like a good time to think about a road map for our next few releases. Lots of questions:

• When do we want to get the final versions of ML-KEM, ML-DSA, and SLH-DSA included?
• When do we do a 1.0 release?
• When do we pivot from describing the project for being for research use versus more production oriented settings?

Here are my initial thoughts around liboqs: I think the necessary conditions for a 1.0 release are both that we have at least the final versions of ML-KEM and ML-DSA, but also that we have made substantial progress on our pivot from research to production-oriented use. I think that pivot will take several months, but I think we can and should get ML-KEM / ML-DSA out there sooner. So my initial proposal would be:

1. Do a liboqs 0.11.0 release by early September based on the various functionality and updates since the 0.10.0 release in March 2024.
   • Of the remaining issues open for 0.11.0, the critical ones to resolve would be Kyber libjade and updating Ubuntu CI. I think all others are optional.
2. Do a liboqs 0.12.0 release by end of September / early October, the sole purpose of which would be to include an implementation of ML-KEM and ML-DSA, likely pulling from PQ-Crystals. (Perhaps there will be other things included in 0.12.0, but we would not hold the release for any of them.)
3. Aim for a liboqs 1.0 release near end of 2024 / early 2025 which starts to pivot from research to production-oriented use.
4. Perhaps there will be another release between 0.12.0 and 1.0 if there's a significant chunk of new functionality to be included, but that's optional. I think our focus during that period should be primarily on the pivot from research to production-oriented and less about new functionality.

It will also be really important to align this with oqs-provider: @baentsch, what are your thoughts on where oqs-provider is going?

Tagging @open-quantum-safe/tsc @open-quantum-safe/core for feedback, and welcoming feedback from anyone in the community.

[bhess]

Thanks Douglas. Your proposal sounds reasonable to me.

I agree that making ML-KEM & ML-DSA available sooner than for 1.0 would be good. The timeframe for a 0.12.0 release sounds realistic to me. If SLH-DSA is available by then, even better.

I also agree that the 1.0 milestone should focus less on new functionality but more on items such as integrating the audit feedback and a prioritized issue backlog.

[baentsch]

It will also be really important to align this with oqs-provider: @baentsch, what are your thoughts on where oqs-provider is going?

The simple answer (you probably want to hear): Wherever liboqs goes:

oqsprovider has been designed and implemented to be so fully automated/scripted that anyone can now make it follow any liboqs updates, e.g., in terms of algorithms supported. Thus this "roadmap" (or any other algorithm prioritization/release list/schedule) can easily be supported. In that sense, "alignment" is irrelevant/guaranteed (unless someone wants SHBSigs supported :). Edit/add: Proof point: unassisted addition of Cross.

The more complex answer (you probably don't want to hear): I see liboqs (OQS in general, actually) to be extremely risky software to make "productively" available to the "unwary". Top 3 reasons:

1. it integrates and depends on software from some upstreams with unknown (or at least undocumented) maintenance and quality standards; [edit/add the word "some" to avoid misunderstandings]
2. it is governed by an organization (PQCA) that considers "productive software" anything that is used by someone "productively" and does not want (to take time?) to commit to concrete quality goals (see the many open issues on "project lifecycle" at https://github.com/PQCA/TAC/issues);
3. it has a razor-thin active contributor base ("key person risk", anyone?) [edit/add for the avoidance of misunderstanding: I understand under "active contributor" someone dedicated (with a certain portion of his/her time) to supporting the code, fixing bugs, assisting the community]

For these reasons, my thought as to where "oqsprovider is going" is that it should serve in the short term as the prime mechanism by which liboqs should be consumed. Top 4 reasons:

1. liboqs is by design and by management a research vehicle containing some uncontrolled, unmaintained and sometimes already dubbed "borderline irresponsible" code; [edit/add the word "some" for avoidance of misunderstanding and added link to original use of that term]
2. oqsprovider can (partially already does) disable/leave out the most harmful/risky liboqs code paths via configuring liboqs in a "suitably limited" manner;
3. Embedding/making available PQ algs this way via the APIs of OpenSSL puts another layer of (ab-/mis-)use control over liboqs;
4. This allows PQ integration into binary distributions without bespoke (and thus, risky in terms of mis-use) integration code for use by the "unwary".

To serve this purpose, however, it needs much more work (part of which I hope can come out of cncf/tag-security#1333 and help by people like @anvega ).

But for the avoidance of doubt, I will not do this work (alone again?). Thus, it may well be that the real answer to your question @dstebila will be "oqsprovider aims to remain useful for experimentation" (but nothing beyond that). But this answer applies to liboqs in the same way:

I also agree that the 1.0 milestone should focus less on new functionality but more on items such as integrating the audit feedback and a prioritized issue backlog.

Good first steps, but the problems this project needs to solve go much deeper: If we'd agree that a 1.0 release should mark the transition of the project from one created and managed by and for cryptographers & researchers to one aimed to reliably serve the general public (?), results of a single tiny audit or issue prioritization are band-aids (if I'm phrasing it nicely; "eyewash" is a more apt term coming to mind): This project needs security engineering, people solving the issues, caring for responsible use(rs), i.e., committed and qualified (not just in cryptography but also in security engineering) contributors and maintainers that are driven by something like the OpenSSL mission and not short-term quarterly goals, pure company marketing tag lines or the next paper deadline.

Labelling liboqs alone as "fit for productive use" (in the way I understand it) is way more than a "pivot". It requires active contributions and sustained maintenance by professional and committed security engineers making the use of a "don't-hurt-yourself-protective-layer" like oqsprovider unnecessary. I'm afraid this will take way more than a few months: IMO it will require the on-boarding of such people and moving them in positions of responsibility that PQCA and LinuxFoundation currently only has (wants?) "non-committal" (or over-worked/differently focused) researchers in.

[SWilson4]

Now that the final version of ML-DSA is available upstream, is it worth delaying 0.11.0 until we pull it into the library? Otherwise it seems we may be doing 0.11.0 and 0.12.0 a week apart.

[baentsch]

is it worth delaying 0.11.0 until we pull it into the library

imo, absolutely. Last time we needed a week alone for the oqsprovider-release-sing-and-dance....

[dstebila]

Agreed.

[bhess]

A few arguments for postponing ML-DSA to a 0.12.0 release:

• The API needed for testing the current NIST ACVP vectors is still to be integrated upstream: Question about any differences from PQC standard final version pq-crystals/dilithium#88 (comment)
• NIST ACVP vectors against the external API (that will be exposed to the user) are expected by October: ML-DSA: integrate final standard #1891 (comment)
• FIPS 204 (and FIPS 205) specify additional "pre-hash" variants that may need some more discussion on how (and if) they should be integrated

I therefore think that targeting an October release with ML-DSA will lead to a more tested and complete integration.

[planetf1]

I'd like to also propose we add pq-code-package 'integration' to the roadmap (I can open an issue).

When we created the project our vision was to have a variety of standards-track algorithms available with a focus on assurance (tests, constant time, code analysis, audit etc, & explanation of characteristics) which would then feed in to liboqs

We don't have implementations ready for this yet, but I think we should clarify, document, & if appropriate track this initiative.

Current pqcp activity is focussed around ML-KEM, but ML-DSA & SLH-DSA should follow.

[planetf1]

I think refinement on the project 'planning' (at least making it easier for others to know where best to contribute) is important -- added some comments to discussion. This could be very useful for liboqs too given the points about it's relevance and need for broader contribution.

It does not in itself fix any problems, but it could be an enabler for that.

[baentsch]

I'd like to also propose we add pq-code-package 'integration' to the roadmap (I can open an issue).

Are you sure this is an issue for OQS, not rather one for PQCP, @planetf1 ? We already are hard-pressed to make use of upstreams turning unreliable like PQClean -- I'd be very hesitant to add another one in this situation. My strong suggestion in turn would be for PQCP to adopt the copy_from_upstream logic so OQS integration is smooth (if/when desired and if/when code is available).

[planetf1]

It is primarily PQCP. Over there we need to line things up to make any transition smooth - we will work towards this.
My point of bringing this up was just to indicate it as a longer term vision on the roadmap.

[baentsch]

One excellent suggestion (I think by @ashman-p ) was to document the quality / support assertions provided by all OQS upstreams as a part of the quality assertions OQS wants to give.

But that again requires a list of quality assertions we'd like to give (and get from others). Proposals for list items welcome. Not making progress on this would be really bad, considering there's lots of alternatives to OQS springing up right now...

fwiw, we're discussing such criteria (labelled reliability criteria) for oqsprovider. Comments/improvements on those (or a separate list for liboqs(?) welcome).

Oh, and we need to agree whether those assertions should apply to all of OQS or only to select sub projects (open-quantum-safe/tsc#2)...

[planetf1]

Worth tracking in a new thread or issue?
On the last point I would imagine the same criteria would be used across subprojects, but the responses will vary by subproject. Some will have 'more', others less - and maybe nothing if it's archived, or otherwise low priority/idle subproject.

[Baobsch]

Hey guys, is there a planned date for version 0.12.0 release (which I believe should implement the final version of ML_DSA standard) ?

[dstebila]

We're currently aiming for somewhere around 2 weeks, although we've gotten into an API discussion which might delay things. You can follow the progress of the ML-DSA pull request here and the 0.12.0 tracking milestone.