Retrieve the names of available signature algorithms in the age of providers about openssl HOT 7 OPEN

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.

from openssl.

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.

from openssl.

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.

from openssl.

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:

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

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.

from openssl.

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?

from openssl.

Can the list app get access to sigalg_lookup_tbl?

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

from openssl.

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?

from openssl.