Adding OpenSSL CLA requirement

[planetf1]

One of the potential projects consuming code from liboqs, and pq-code-package is OpenSSL.

In order for any code to be considered by OpenSSL, all contributors (current, future, and historical) are required to have signed the OpenSSL CCA. This is very similar to the Apache CLA. This will apply both at the individual contributor and organization contributor level.

Note that this in no way means it's certain OpenSSL will actually use our code. They are still evaluating the approach they wish to make. This is merely a prereq for consideration.

This discussion has been ongoing at the PQCA level both in terms of general approach ,as well as tooling to support.

As a TSC we need to consider if we are ok with this approach, whether we have any particular concerns, and provide feedback to the PQCA.

Suggest discussion at the 20241106 TSC meeting

[planetf1]

OpenSSL CLA

[mkannwischer]

It would be great to have mlkem-native in OpenSSL.

Two points:

1. @potsrevennil and me are happy to sign the CLA for mlkem-native and I don't see any issues with our employer signing as well. @hanno-becker and @rod-chapman, how do you think about this?

2. Is see that openssl recently merged ML-KEM-768 from Boringssl in ML-KEM768 openssl/openssl#25848 into a feature branch. It would be good to understand how much they are looking for more parameter sets, more optimized code, or more assurance. Maybe @baentsch or @dstebila do have some more information on this that they could share with us, please?

[baentsch]

Thanks for tagging me @mkannwischer . Sure I can give some background: These discussions started before the establishment of PQCA (see openssl/project#431 for "history" and rationale). When they then didn't really progress, as a long-time OpenSSL contributor, I more recently chose to re-prioritize my non research-community-targeting FOSS contributions to that project where we currently proceed implementing all standards in a way completely separate from PQCA for various reasons, (missing) CLAs being one. fwiw, SLH-DSA is the most mature, but work is proceeding on the other algs as well, incl. ML-KEM, see e.g., openssl/openssl#26006.

That said, as I am an independent contributor myself, I personally love to work with any other independent contributor on the same terms of any given FOSS project. So if indeed in this case all authors (and where applicable, their employers) of an ML-KEM implementation are also willing to contribute under the same terms, let's discuss concrete ways forward, ideally in an open forum like openssl GH. While I by now also appreciate the boringSSL APIs, there's (as always) room for improvement, so you may consider responding to openssl/openssl#25879 for example as and when you'd be willing/able/permitted to contribute and make OpenSSL better. Another approach may be for you to open further issues at OpenSSL explicitly targeting functional and non-functional benefits of alternative code bases. That way, the whole OpenSSL community can chime in as to merit and priority of such features. In this case, please be sure to use the tag "ML-KEM" in the issue header so they're easier to find in the "sea of issues" :-) Tagging me also would help. Or even more simply, just open a PR -- in the case of ML-KEM, be sure to target the feature branch of that name for now. Thanks in advance!