New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding signature algorithms via provider interface #19312
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good for the most part.
doc/man7/provider-base.pod
Outdated
|
||
The "TLS-SIGALG" capability can be queried by libssl to discover the list of | ||
TLS signature algorithms that a provider can support. Each signature supported | ||
can be used for client- or server-authentication in addition to the build-in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
built-in
not build-in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so changed in e558217
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems not to be fixed after all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, what's not done is s/build-in/built-in/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now done.
Thanks for the review, @paulidale. I'd like to ask for advice on one more thing: How much effort should be put in the development of a dedicated "fetchable sigalgs" test case for this functionality within the Background: The oqsprovider has tests that exercize these code paths much more than anything "artificial" in the With fetchable sigalgs it's now different, though: oqsprovider already does (X.509) encode/decode --for which there are even (OQS-)OpenSSL1.1.1 interop tests and this PR now uses those certificates with the new dynamically fetched signature algorithms. This "external" testing even discovered --by the sheer number of algorithms added-- previously unseen OpenSSL bugs. --> Should all of this ("artificial" sign/verify combined with encode/decode for cert/key file generation) be re-created in the |
I'll flag the testing for OTC discussion, relying on OQS testing requires an exception to the testing required rule. OTC: is the OQS testing sufficient or does there need to be an artifical test in OpenSSL? |
IMO external testing should only ever be supplementary. We should have our own tests that we can easily extend and modify as required over time. For example, lets say we encounter a bug at some point in the future for this feature that was not picked up by the oqsprovider external testing. Without our own tests to build from we cannot easily add a regression test for the bug. Also consider the case where the maintainers of an external test decide to take things in a different technical direction and no longer maintain the old external test code. Without our own testing we could lose the test coverage we get there. |
I agree that we need our own tests here but don't think we are to put this burden on the developer of this PR |
Agreed -- but this is not time-critical now, right? This could be done as and when the need arises.
Completely understandable. I can promise to move all required code (basically gutted to not use So what about creating a new issue for this and I (or anyone else with too much time :) works on this separately along the lines of
|
The test policy says this:
But it also says:
https://www.openssl.org/policies/technical/testing.html So I would be ok if the tests are not added in this PR but are instead added via a follow up PR - as long as there is a real commitment to actual produce such a PR! |
There definitely is. My goal is to be a trusted contributor -- not just to OQS but also to OpenSSL. FWIW, I started doing OSS when at university in the last century (sigh :) and "only" had to suspend it during the time my (ex-)employer prescribed what I do. But now I'm free again to make good on my words! Splitting things has the great benefit that different activities can proceed in parallel:
The separate issue for this is now opened: #19369: Please comment/amend as you see fit. In turn, I'm now asking for Review on this PR. |
Removing the hold since the decision seems to have been made in favour of having our own test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. Mostly minor comments below. I am surprised not to see any changes in the X.509 code....do we already have everything we need there for certs with provider based sig algs? Is it just a case of the provider registering the correct sigalg oid? I know we talked about this previously but I forget where we ended up.
Also - I'm looking forward to seeing a test for this (in a separate PR). There's quite a lot of code here that I'm anxious about in the absence of that test.
Oh....this is a significant feature, so it should have an entry in CHANGES.md |
@mattcaswell Thanks for the review.
Working on it -- but it's an even bigger piece of work than I originally anticipated: The updated test tls-provider not only will "invent" a sig alg and encode/decode logic but also has to have an additional test hash alg as oqs-provider doesn't trigger the "additional hash alg" logic (none of the PQ sigalgs needs a digest). Your feedback above tempted me briefly to completely eliminate (the already optional) support for a pluggable sigalg provider to set a hash alg: oqsprovider doesn't need it, the current openssl core logic isn't quite geared to handle the situation and the new tests are pretty convoluted. But then again, I don't want to shy back from a conceptually sensible/logical feature just because of the effort involved. All thoughts/preferences/suggestions from your side welcome. Edit/Add: The more I think about it, the more I am (now also) convinced that #19369 needs to be fixed within this PR. The only reason speaking against that would be if OpenSSL3.2 would be released before I get that done: Can you share your timeline for that? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your feedback above tempted me briefly to completely eliminate (the already optional) support for a pluggable sigalg provider to set a hash alg: oqsprovider doesn't need it, the current openssl core logic isn't quite geared to handle the situation and the new tests are pretty convoluted. But then again, I don't want to shy back from a conceptually sensible/logical feature just because of the effort involved. All thoughts/preferences/suggestions from your side welcome.
Yeah - conceptually it seems to make sense to have this capability.
Edit/Add: The more I think about it, the more I am (now also) convinced that #19369 needs to be fixed within this PR. The only reason speaking against that would be if OpenSSL3.2 would be released before I get that done: Can you share your timeline for that?
That would be great. The 3.2 freeze won't be for some months yet so you've got some time.
ssl/t1_lib.c
Outdated
sinf->hash_algorithm = NULL; | ||
} | ||
else if (p->data_type != OSSL_PARAM_UTF8_STRING) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since one else branch uses {}
our coding style says that all branches should use {}
even if they are only one line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So done in all places in 8be6985
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem to be actually done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, @mattcaswell is correct. Since the else
body a couple of lines down is bracketed, all of the if
... else if
... else
bodies must be bracketed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now done
ssl/t1_lib.c
Outdated
ERR_raise(ERR_LIB_SSL, ERR_R_PASSED_INVALID_ARGUMENT); | ||
if (p == NULL) | ||
sinf->oid = NULL; | ||
else if (p->data_type != OSSL_PARAM_UTF8_STRING) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All branches should use {}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 8be6985
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, all of the if
... else if
... else
bodies must be bracketed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
@paulidale @mattcaswell @levitte Thanks again for your feedback. With the latest commit all of it should be addressed. Instead of commenting on each of your comments, may I ask you this time to mark things resolved as you see fit and let me know if/when anything still needs to be addressed?
This already works:
|
All of my comments seem to be addressed with the exception of the one seeking input from @levitte. I have marked them as resolved. |
Uhmmm, I did comment on that: #19312 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
24 hours has passed since 'approval: done' was set, but this PR has failing CI tests. Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually. |
Merged, thanks for the contribution. |
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #19312)
Woop! Thanks to @baentsch for this cool feature! |
Also very glad to see this. Thanks in turn particularly to @levitte @mattcaswell @paulidale to "shepard" this through. Only little concern remaining: Why is there a "symbol error" in cross-compilation CI now? |
Seems somehow related to #20331 which was also recently merged. |
https://build.opensuse.org/request/show/1092835 by user msmeissn + dimstar_suse - updated to 0.5.0: - oqs-provider now also enables use of QSC algorithms during TLS1.3 handshake. The required OpenSSL code updates are contained in openssl/openssl#19312. * Algorithm updates All algorithms no longer supported in the NIST PQC competition and not under consideration for standardization by ISO have been removed. All remaining algorithms with the exception of McEliece have been lifted to their final round 3 variants as documented in liboqs. Most notably, algorithm names for Sphincs+ have been changed to the naming chosen by its authors. * Functional updates - Enablement of oqs-provider as a (first) dynamically fetchable OpenSSL3 TLS1.3 signature provider. - OSX support - Full support for CA functionality - Algorithms can now be se
First cut tacklingFixing #10512as per discussion there. Fixing #19369.Still considered WIP: Missing e.g. is a test within the OpenSSL test harness. Testing right now done via oqs-provider. Testing available in https://github.com/baentsch/openssl/compare/sigload...baentsch:openssl:sigload-test?expand=1