Retrieve the names of available signature algorithms in the age of providers

[baentsch]

As suggested in the discussion below, this is to propose a new openssl app, or extension to an existing app like list or an external script facilitating the retrieval of currently available signature algorithms in a form suitable for consumption by the openssl config file.

Discussed in https://github.com/openssl/openssl/discussions/24522

^{Originally posted by **baentsch** May 29, 2024} The [provider mechanism](https://www.openssl.org/docs/man3.3/man7/provider.html) allows (potentially many) different signature algorithms to be accessible to the `openssl` TLS logic. The [openssl config](https://www.openssl.org/docs/manmaster/man3/SSL_CONF_cmd.html) mechanism allows the ones actually active to be configured/limited, e.g., to [work around server problems with too many active signature algorithms](https://github.com/open-quantum-safe/oqs-provider/issues/399). The question now is: Is there a mechanism by which the unwary user can retrieve a list of all permitted values to the "SignatureAlgorithms" config parameter, e.g., along the lines of `openssl list -signature-algorithms` (which does take providers into account, but does not output "fully qualified" algorithm names for use by the configuration, e.g. and incl. hash algs)?

[beldmit]

I'm not sure it's doable in general. E.g. when we have a 3rd-party provider providing a signature algorithm working together with some common hash algorithm taken from the default provider.

Probably a provider documentation + some testing against the current configuration file will be OK.

[baentsch]

I'm not sure it's doable in general. E.g. when we have a 3rd-party provider providing a signature algorithm working together with some common hash algorithm taken from the default provider.

Agreed. But should such providers not register a suitable name? But then again, as per @levitte 's comment providers only register the sigalg name, not the TLS one....

Probably a provider documentation + some testing against the current configuration file will be OK.

The original problem by @mouse07410 would arguably not be solved that way as the use case there (if I got it right) encompasses more than one provider.

[mattcaswell]

s there a mechanism by which the unwary user can retrieve a list of all permitted values to the "SignatureAlgorithms" config parameter, e.g., along the lines of openssl list -signature-algorithms (which does take providers into account, but does not output "fully qualified" algorithm names for use by the configuration, e.g. and incl. hash algs)?

There is a programmatic mechanism to query all the available providers about TLS SignatureAlgorithms that they want to plug in. Providers adding new TLS SignatureAlgorithms do so via the TLS-SIGALG capability, which can be queried via the OSSL_PROVIDER_get_capabilities() function. Libssl does exactly this to query all providers, e.g. see:

https://github.com/openssl/openssl/blob/9fcf57b45985336b04579dd317d0dc990a9c062b/ssl/t1_lib.c#L692-L733

The complication is that libssl adds the provider plugged-in sigalgs with its own hard-coded built-in list:

https://github.com/openssl/openssl/blob/9fcf57b45985336b04579dd317d0dc990a9c062b/ssl/t1_lib.c#L1509-L1595

So the full list of TLS sigalgs are the combination of these two things. The above code also checks the built-in list to confirm if it is actually usable from the available providers. Only available sigalgs from the combined list are actually usable by TLS applications.

So, it would be feasible to extend the list app with a way to query the capabilities of the providers to see what TLS sig-algs can be plugged in. But there is currently no mechanism to query which of the "built-in" TLS sig-algs are actually usable.

[baentsch]

So the full list of TLS sigalgs are the combination of these two things.

Right. One actually would only have to traverse the list of all currently active TLS_SIGALG_INFO structs -- also delivering the hashes. Let me give that a try extending the list app...

But there is currently no mechanism to query which of the "built-in" TLS sig-algs are actually usable.

Nevertheless it shows which ones may be available (in sigalg_lookup_tbl), right? And that was the original ask: How does the unwary user learn about the names of all possibly configurable (TLS) "SignatureAlgorithms". Only question in my mind right now: Can the list app get access to sigalg_lookup_tbl?

[mattcaswell]

Can the list app get access to sigalg_lookup_tbl?

Unfortunately not - this is an internal global variable in libssl and is not exposed.

[baentsch]

Can the list app get access to sigalg_lookup_tbl?

Unfortunately not - this is an internal global variable in libssl and is not exposed.

Hmm -- may I ask what you'd think about these two initial thoughts for ways how to deal with this then? 1) Would it be OK to consider adding an API to do so, e.g., by populating a (then also publicly accessible) TLS_SIGALG_INFO list from that struct? This would arguably be a sub-optimal solution as that'd perpetuate this "internal" mechanism, though. Sub-thought: There seems to be an "apps"-based subset of the information in sigalg_lookup_tbl, namely in signature_tls13_scheme_list: Would that be something that an app listing the "built-in" TLS sigalgs could sensibly use (and maybe extend to be completely in sync with sigalg_lookup_tbl)? But duplicating this information also feels wrong (brittle code if only one place gets changed). 2) What should happen if one queries the default provider just like a "normal" provider: Would that be a way to glean the same information as in sigalg_lookup_tbl? Or do I see it right that one first would have to enhance the "built-in" provider(s) to follow the provider documentation concerning the "TLS-SIGALG" Capability (that I created, admittedly :)? This at first glance seems doable, mirroring the logic in for TLS groups: Would this be worth while doing/a welcome enhancement in general and beyond this issue?

[nhorman]

I believe the answer to question 1 is yes, its always ok to propose/consider a change like this. I would encourage you to open a pull request. We can't guarantee the outcome of course, as thats dependent on the review of the pr and issues that may be identified with it. If you're not ready to invest the time in a full PR, I would encourage you to write a design document here first for an initial comment round to better determine its feasibility.

[mouse07410]

Each provider should "provide" a list of algorithms it supports (for use in pkeyutl and such), and a list (subset) of algorithms it wants to export to TLS. If only one list is provided, it's used for both.

Any other attempt to approach this problem is likely to turn out more curbmersome and taxing than the one proposed above.

[nhorman]

@mouse07410 @baentsch are either of you willing to compose a PR for this? I'm happy to assign it to you as a community issue

[mouse07410]

I'm not - I've neither competence nor time for that.

Not to mention that I think this whole approach is bad/barely-sustainable, and a simple added ability for each provider to report two algorithm sets would be an easier-implementable solution, suitable for both short-term and long-term.

[baentsch]

@mouse07410 @baentsch are either of you willing to compose a PR for this? I'm happy to assign it to you as a community issue

I can surely give this a try for all "documentation-supporting" providers (as per the suggestion by @mattcaswell , it would be a cut-copy-paste of the code I already did for the implementation of the "TLS-SIGALG" capability); for the built-ins, well, it'll take a (arguably separate) PR to add the "TLS-SIGALG" capability to default and FIPS provider. I'm still not entirely sure how to properly capture all digests the sigalgs may support...

[paulidale]

A new provider side API (or APIs) might be the way to go here.

With a single new API, a provider could advertise all the sigalgs it supports in isolation. Better might be multiple API that combine to handle the various different parts (in the TLS 1.2 world, I'm not sure how 1.3 would cope).

[baentsch]

A new provider side API (or APIs) might be the way to go here.

Something like "give me a colon-separated list of all (EVP|TLS) sigalg/hashalg combinations you support"? Would surely be more simple than querying capability sets...

[beldmit]

I'm not sure I get how do you plan to use this API and why it's better than documentation

[baentsch]

I'm not sure I get how do you plan to use this API and why it's better than documentation

Partial answer to this was the reason for asking which API @paulidale and/or @mouse07410 had in mind (?). My thought was to use it with an extended version of the list app.

Another partial answer is that documentation is not solving the issue as well as code: Different provider (version(s)) will support different algorithm sets. Also, different openssl versions (particularly if configured with different built-in providers) will provide different algorithm sets. And lastly, the current documentation seems to be too difficult to understand for @mouse07410 -- and s/he never appeared to me to be not capable (incl. grasping documentation), so it'll be a harder problem for the "common Joe User" (to know which algs are available with a currently configured collection of binaries (openssl/libcrypto + providers)).

[nhorman]

Ok, so what I'm reading here is that based on @paulidale comment, we have an idea for a provider api to accomplish this, and @baentsch is willing to take a shot at writing it. Thank you @baentsch !

I'm assigning this as a community issue to you, please link your PR here when you have it available.

[baentsch]

@baentsch is willing to take a shot at writing it.

That's a gross oversimplification :-) but OK. @paulidale : Could you please be more specific what (new?) API you had in mind? I'd otherwise proceed using the already defined "sigalg-name" capability to extract (TLS) alg names for the list app (as basically proposed by @mattcaswell ) and augment that with extensions to the default&FIPS provider capabilities to get a complete list.