OpenSSL discussion with OQS project #431
Comments
|
I followed-up with an email to the ongoing discussion with OQS/U. Waterloo about this. I will collect proposed items here as they are proposed! |
|
Quoting D. Stebila [I am splitting it in 2 separate comments, one for each item proposed so far -- @romen ]:
|
|
Quoting D. Stebila:
|
|
IMO, I prefer (3). Mainly because we operate on many different platforms and environments and we want PQC to be available everywhere that OpenSSL is. If we were to rely on OQS provider, or liboqs directly, then there are sure to be some environments where having both is not possible. Additionally having things like the same licence, and everything bundled up together are a significant benefit to our users (no extra dependency).
This sounds very interesting. The biggest obstacle I can think of here would be CLAs. We need to ensure all contributors have signed the OpenSSL CLA to enable us to accept such code. If we can solve this problem then I think this option would work very well for us (assuming such implementations are C based). |
|
I agree with (3). If they have not started yet — it would be good to ask them to review our ICLA/CCLA so they can determine what will allow them to comply with that in future. |
We are likely to have many contributors to the PQ Code Package project, and it would seem odd to require people submitting code to that project to also agree to the CLA of a downstream project that may (or may not) use that code -- and not scalable as well, if many downstream projects want to adopt the code and each requires the upstream contributors to accept the downstream project's CLA. We're intending to use Apache 2 for the PQ Code Package, which is the same license that OpenSSL uses, does that suffice for code sharing? |
Unfortunately not, no. This will be a critical issue for us. |
In that case, do I understand it right that you need someone with a CLA to write all code from scratch? No reference code usage etc. permitted? I'd otherwise have offered to re-do "oqsprovider" (this time 100% alone as I have a CLA and not just 95% :), but of course, that wouldn't solve the core crypto code (ownership issue) as we import this from various upstreams (e.g., the NIST reference submissions). |
|
All code submitted to OpenSSL must be accompanied by an ICLA for all authors involved (additionally a CCLA if the authors wrote the code on behalf of an employer). In the case where code already exists that you want to incorporate in a submission to OpenSSL then either (1) the code must be rewritten from scratch by someone with a CLA or (2) all original authors of that code must be contacted and must also provide a CLA. Every once in a while we get asked if we can make an exception - but in the (nearly) 8 years since this policy was introduced we have never granted one. There is a current discussion about reviewing that policy (see #424) - but I suspect it is unlikely we will make significant changes anytime soon. |
Personally, I find that unfortunate. FWIW, while employed this policy prohibited me from contributing to OpenSSL. I could begin the work I did on the project (incl. all enhancements to the provider concept and
? This statement reduces a bit my motivation to keep working on (1), even though |
|
I would like to add that (1) does not conflict with (3) - I definitely do not expect OpenSSL own provider(s) (especially if the CLA policy isn't changed) to include that many algorithms as oqsprovider. If the implementations are compatible, which they should be in case the same algorithm is implemented, the implementations can have different characteristics for example speed/size tradeoffs. If users are willing to use 3rd party providers they can still benefit from oqsprovider even if OpenSSL includes some PQ crypto algos. |
Absolutely! I am of the opinion that oqsprovider is hugely beneficial to the OpenSSL ecosystem. Please don't take my statement as any criticism of oqsprovider! I think there is plenty of scope for both to live side-by-side. oqsprovider is fulfilling a very different need to what mainline OpenSSL provides. My guess is oqsprovider will probably always be "ahead" of OpenSSL in terms of the latest-and-greatest and with a broader range of options. It will probably be "faster" to react. Algorithms integrated into OpenSSL mainline will be fully standards based and cross platform. The "core" tried-and-trusted algorithms that it is important that we get to everyone. I fully expect oqsprovider to still be a very useful provider even after some PQ algs are in mainline OpenSSL. |
|
How does our current policy square with |
This was a code pre-existing in the source tree before the adoption of the CLA policy. |
|
I for one am unsure about (3), and @baentsch's reaction (which I expected) has me lean towards not being particularly positive for that option. Yeah, I understand that this might make things difficult on some platforms... but turning things the other way around, could we think of helping https://github.com/open-quantum-safe/oqs-provider.git ? I.e. could we, the OpenSSL folks, think of contributing some time to related projects? The time spent would most likely be less than to integrate OQS into OpenSSL, with everything it entails in terms of rewrite (which most definitely is a factor regard the build system). |
|
OTC: The pros/cons with these options are mostly non-technical but rather business matter. |
t8m
changed the title
That would be awesome -- and not unheard of: You, @levitte already did that extracting my original oqsprovider code from our fork and I tried to reciprocate enhancing some general OpenSSL provider mechanism shortcomings. But right now, I don't think this would be really called for -- what would help definitely, though, is guidance as to what it'd take to bring oqsprovider more "in line" with regard to platforms, testing and deployment such as to increase the chance that anyone packaging openssl can do the same with oqsprovider for the same environments? The creation of oqsprovider issues pointing to the right requirements would go a long way.
True about the original 3 options. But there's also technical options, so let me continue the numbering:
|
|
It might be nice to have the build of external providers integrated in some way into the OpenSSL build system, e.g. By doing this we could integrate some testing into our own CI testing - so that we can at least confirm everything works on all the same platforms that we cover via our CI. I'm still of the view that we will need to integrate some PQ algs directly into OpenSSL. But if we can make incorporating external providers as easy as possible, this at least lowers the bar for using them. |
ghost
assigned 
|
@mattcaswell Adding a placeholder to discuss on F2F AU |
|
External providers that use CMake should be quite easy to integrate well enough. At this point, CMake is pretty well rounded, including uniform command lines to build and to test on all platforms that CMake has been ported to, so we don't have to worry very much at all about what command line shell is used. |
|
Thanks everyone for the conversation. I am keenly interested in this as well and also agree with Matt that having these (ultimately) delivered as part of OpenSSL package would be great. But, saying that, the provider framework does give folks the ability to add a PQ provider without too much difficulty. I know Michael and Norm on my team (and others at OQS) have been doing great work in this area. A fantastic first step (in any of these directions) might be the CI/CD approach as mentioned. We currently do something similar on my team using our internal fork of OpenSSL. Anyway, glad to see this conversation! Thank you all for your work.... it is invaluable. |
Thanks for the feedback, @dieseldad60 -- great to hear! Can I take this as a voluntary statement of interest to help out the team, e.g., on open-quantum-safe/liboqs#1691? :) Also, feedback on https://github.com/orgs/open-quantum-safe/discussions/1689 solicited should you not yet have registered to OQS discussions... |
|
@baentsch , hopefully we are helping. I didn't notice I was logged in via personal email. Norman Ashley is on my team and we are trying to contribute in multiple ways :). Looking forward to more! |
|
It seems this discussion has "fallen asleep" a bit since OQS has been folded into PQCA/LinuxFoundation, so can I revive it somewhat (regardless)? Allow me to take openssl/openssl#24997 as a starting point wondering what it would take for OQS to cooperate on similar terms as discussed there? Also, there's currently a discussion whether/how to change the goals of OQS (IMO to maybe more align with those of OpenSSL) -- where the OpenSSL team's perspective would surely be beneficial to arrive at a good and practically actionable outcome: Feedback here or in that issue very welcome! |
At its simplest, what would be required is for OQS to adopt the OpenSSL mission and values: The objective for the OpenSSL/BouncyCastle/Cryptlib co-operation is to ultimately deliver more than that and exactly what form that will take is subject to further discussions. I'd be happy to have a call with OQS representatives to explore if there are opportunities to work better together. |
That should be straightforward (I hope). I personally already do and reference/argue for this whenever I can (last time just yesterday).
What do you prefer as "representatives" for such call? More admin style folks not actually doing code/GH contributions or rather "doers"?
Notwithstanding the benefits of a call, any chance you could share here already concrete areas (list of GH issues, say) that FWIW, personally, as a truly independent contributor I'm open to all sensible suggestions -- ideally things that benefit the widest possible range of people. |
Well, I guess it depends on what level of co-operation we want to achieve. Are we talking about a purely technical level of co-operation here? Or something more significant?
openssl/openssl#22203 immediately springs to mind as something we need to get done. We are of course also looking to get our own implementations of ML-KEM, ML-DSA, SLH-DSA. I know there was some talk earlier in this discussion about providing clean stand alone implementations of these with a view to making them something that other libraries could integrate. I'm not sure where that go to - but it remains an interesting concept (notwithstanding potential CLA issues). Once suitable implementations are identified there is going to be a big chunk of work involved in integrating those into our own provider architecture. |
|
There are two aspects here @mattcaswell is alluding too - how do we help cooperate with other efforts (and being unde the mission helps) and how do we get workable PQC implementations to the users of the openssl library. What our users want (and have communicated) is that PQC algorithms are supported in the base distribution of the openssl library that are interoperable. And there are two parts (at least) to that - one is the actual algorithm implementations, and the other all the plumbing that goes with it. A simple thing that would make sense is to get the oqs-provider code (which is a much smaller set of developers/contributors) covered for contribution under the CLA - you don't have to do the work of contribution yourselves - but you can enable others to contribute by having a CLA in place. That helps. The collection of implementations under liboqs is a different challenge to deal with. Getting a decent set of test vectors in place for interoperable usage on actual OIDs and not "dummy" ones is something that needs to happen - the majority of the PQC work out there in use is still very much in the pre-production "play" context rather than setup for actual interoperable usage. |
|
For the clean implementations, this project would be the possible source of code - CLA of course is still a blocker. |
|
One of the members of the legal team at Linux Foundation has said they're happy to discuss to try to find a way to work through the CLA issues. I'm led to believe that they had some involvement with OpenSSL's big relicensing effort some years ago. I can make some connections here to set up a discussion if you're interested. We're hoping that there are two possible pipelines that could be of interest to OpenSSL -- the existing oqs-provider for adding PQ algorithms via the provider interface, and new work in the PQ Code Package project that could be a starting point for OpenSSL's implementations. |
|
What is the relationship between pqclean and pq code package project? It looks like neither have versions based on the published NIST standards so far? I assume these are being worked on? For CLA I see pqclean has 23 contributors according to: This is at least a tractable number of people to reach out to and ask for a CLA. |
PQ Code Package is in some sense the successor to PQ Clean, albeit PQ Code Package will be focused solely on standardized algorithms, starting with ML-KEM. The implementations in PQ Code Package do aim to be based on the published NIST standards, and are generally in the process of updating to do so. |
Two thoughts on this: 1) It'd be trivial to do this: I am working under the OpenSSL CLA, about 90% of the oqsprovider code is from me and I could easily write a new provider to bring that to 100%. That said, 2) I do not think that'd really help, as indeed the community interest is to have the NIST std algs in (the) default (provider), so there's arguably limited value for a truly new provider -- except as for interop test vehicle -- which is sth oqsprovider contains features for. |
Hmm, if I'm not totally mistaken (@dstebila?) neither PQClean nor PQCP GH authorship is 100% indicative of (legal) code authorship which I think the CLA aims for (@mattcaswell ?): The former pulls in further upstream code bases (by other, "invisible" authors) and the latter uses "many authors"/external tooling to generate the algorithms' code. |
Yes, I think that's right. |
It would be useful and productive so that anyone with an implementation has a quick path to contribute with a mechanism to have it working. The community interest is to have it in the default distribution - not necessarily in the default provider as such. That is a separate decision to make later on. Having the plumbing so any pqc implementation can be trivially plugged in is a positive step forward. Getting that provider contributed under a CLA is an excellent step forward. Then anyone can build on top of it and contribute. |
That's an interesting thought. We built quite some tooling in Coalescing those into one would create such mechanism for PQC authors working under OpenSSL CLA to have their code serve the OpenSSL community right away. This would completely bypass all OQS code (and non-OpenSSL CLA contributors to it). But it would also do away with the benefits of OQS (multi-platform optimizations, common code, hybrid and composite support, etc.). It would also not do away with the use of the OQS/PQClean core APIs that may have IP "connotations" not amenable to OpenSSL CLA use: They're very much based on the NIST PQC competition but I'm not certain whether or not some patent troll may be going after users of this API. That's a topic for the OpenSSL and LinuxFoundation lawyers, I'd say. Again asking @dstebila for his thoughts as the decision for this API pre-dates LinuxFoundation involvement by many years. Finally, tagging @romen on this discussion: Didn't you work on a similar "generic provider builder" project (maybe not PQC specific, but possibly orthogonal/complementary)? |
I am working on such a project, but it is not suitable for merging upstream, because we are working on Rust rather than C+Perl+Perlasm I do agree that if we were able to have CLAs on file for merging the oqs-provider machinery in OpenSSL, with some build time option to enable that machinery to run and fetch the selected implementations, that would be a step forward for mainlining oqs-provider efforts. My understanding is that if the algorithm implementations are not themselves committed into the openssl repository but optionally fetched, then most of the CLAs concerns do not apply anymore. Of course, it would be even better if we could get some of the authors who originally submitted code to pqclean/liboqs/pqcp to sign a CLA and propose their implementation for merging into OpenSSL. That would make the process even simpler for folks that would like PQC into the default provider or as a built-in PQC provider without external dependencies. |
Is that understanding shared by the whole OpenSSL team? If so, things would be really simple: Adapting the new pqprovider's build logic to dynamically fetch (some, TBD) algorithms' code from their origin would be pretty straightforward (using the YML logic mentioned above).
Indeed, that would be preferable. That could then be a contribution by the OQS team: To scour their contacts for true code owners that would be willing to contribute their code to OpenSSL under CLA. |
CLAs apply to all code committed into the OpenSSL repository. If it's not code that OpenSSL itself distributes then the CLA doesn't apply. Of course the reason we have a CLA at all is to protect not only OpenSSL, but also our users. By having such a mechanism we are in part nullifying some of the benefits of having a CLA (our users are no longer protected for that code which we somehow dynamically fetch at build time).
This is by far to most preferable route IMO.
That would be fantastic! |
Agreed, @mattcaswell . It surely is a less-than-perfect solution but may be a stopgap until there comes along a CLA-covered implementation. That said, is there an explanation in detail regarding the user protections afforded by the CLA, particularly In which way they are different from the protections (and obligations towards authors) that the MIT license affords (which is the baseline requirement for OQS)? Maybe such explanation (if sufficiently small) could help convince authors to quickly sign up to the CLA. |
|
@cothan -- with reference to pq-crystals/kyber#31 (comment): Might your code (assuming from the comment it's a "few authors effort") be a candidate for the above (contribution to OpenSSL under CLA)? @cryptojedi: I assume the |
Discussed on 2024-01-30:
Nicola is planning an extended visit to the OQS project.
They are interested in talking to an OTC member about project plans
regarding post-quantum cryptography.
We want to develop a post-quantum cryptography plan but have yet to
do so, therefore it makes little sense to try and represent our position.
However, opening a dialogue with them would be a good idea.
Both OTC and non-OTC groups should engage in dialogue.
Nicola will engage in discussion and form a list of topics which
can be the basis of future group meetings.
The text was updated successfully, but these errors were encountered: