Add naming aliases for standardized algorithms and groups

[baentsch]

In the newly added default provider code openssl by default uses the "hyphen-capitalized-form" from the NIST specification for naming the standardized algorithms (ML-KEM, ML-DSA, SLH-DSA) while oqs-provider has been using for all algorithms for years the "ease-of-use" form without hyphen and lowercase (mlkem, mldsa in this case; no support for slhdsa in OQS).

This issue is to document and discuss a suggestion to add aliases to both forms (openssl/openssl#26328 (comment)).

Advantages:

• Applications using either code base can use the standardized algorithms by way of the same name reference across all openssl deployments (starting with 3.0.0).
• oqsprovider supports both naming scheme preferences of NIST and IETF.

Disadvantages:

• Applications may inadvertently use insecure code (OQS code base) when in fact intending to use secure, production code (openssl default provider)
• This perpetuates a naming form against the NIST spec ( hyphen)
• This adds a naming form against the IETF standards (no hyphen)
• With openssl adding an alias for "non-hyphen" names, users may be tempted to keep using that name, thus inadvertently taking a risk they may not know about (running pure research code that does not have the same quality levels if oqsprovider is active, no property query has been specified and the algorithm fetch order is "surprising").

Mitigating factors:

• The "insecure code use" risk only occurs when activating oqsprovider in the first place: OQS has advised for years against doing that in productive settings, so the risk should be minimal. But people are known to not read warnings and PQCA marketing also is more willing to push risk to users.
• Logic could be added to oqsprovider to automatically disable its own mlkem and mldsa implementations when noticing their presence in the default provider as oqsprovider anyway always needs that for its proper operation.

I'm personally currently undecided which way to go, so further arguments for or against adding this alias mechanism welcome below. Particularly tagging @beldmit @adrien-n for their opinion as "packaging" maintainers.

Beyond the dynamic "standard algorithm disablement option" as mentioned above, I personally also see a more radical solution to this "naming difference" and that is to remove all standardized algorithms from oqsprovider in its default configuration now that these algorithms are readily available in openssl proper. People interested in using the OQS code base for these algorithms can always activate them by way of running the code generator during the build process -- and at that moment, also chose names they like and want to support (either way) -- but adding the clear user warning as per SBOM.

[tomato42]

if somebody wants to use specific implementation for the algorithm, they can always use property query with provider=default or provider=oqsprovider and get that implementation

[baentsch]

if somebody wants to use specific implementation for the algorithm, they can always use property query with provider=default or provider=oqsprovider and get that implementation

Yes, people reading (and understanding) documentation can (often) help themselves. My concern is for those who don't (either :), relying on the "default".

[t8m]

@baentsch please note that algorithm names are case-insensitive apart from when you retrieve them for displaying them to the user.

[baentsch]

@baentsch please note that algorithm names are case-insensitive apart from when you retrieve them for displaying them to the user.

I know (by now) -- and there is an issue asking about making/documenting this consistently with group names: openssl/openssl#26301 (input welcome). Probably need to call this out on the oqsprovider documentation side/site as well.

[baentsch]

Oh, and one more thing: As group names are case sensitive, a complete implementation of this issue would also require adding a "properly cased" alias for group names (currently the same as the algorithm name).

[t8m]

Oh, and one more thing: As group names are case sensitive, a complete implementation of this issue would also require adding a "properly cased" alias for group names (currently the same as the algorithm name).

That's debatable, we might want to change the group name (and sigalg name) matching to be case insensitive. Unfortunately it won't be quite trivial as it requires provider changes.

[baentsch]

That's debatable, we might want to change the group name (and sigalg name) matching to be case insensitive. Unfortunately it won't be quite trivial as it requires provider changes.

Could you elaborate why? Wouldn't this simply be a question of changing group name matching (in openssl core) to be case insensitive?

[t8m]

Could you elaborate why? Wouldn't this simply be a question of changing group name matching (in openssl core) to be case insensitive?

Wouldn't the group name be passed to the provider? Although it should be translated through the TLS_GROUP capabilities entry, these entries are not provider-specific. Hmm... but that is actually an unrelated and much harder to resolve issue.

So let's say oqs-provider keeps using mlkem768 as the group name and we use ML-KEM-768 as the group name. Both providers are loaded and depending on which one is loaded first the SSL context will use different TLS_GROUP capability entry for ML-KEM-768 group. Fortunately we just ignore the group name param so I assume if we used the same group name in our tls group capability entries as oqs-provider does, we could make this particular thing work.

[baentsch]

Wouldn't the group name be passed to the provider?

a) How/where/why? I thought the only item of relevance in operation (for groups) is the code point, not the name(?)
b) Isn't the KEM registration procedure defining which provider entry points are being called later on? Using names during use would imo be counter-intuitive -- but if you have pointers to code doing that(?), please post them and I correct my (mis-)conception.

For all I recall (but it's surely much less than you know about @t8m), the group name only is of relevance when listing groups (now possible with the new list feature -- and hence, now becoming visible -- also in terms of capitalization) and specifying them for use (always possible via -groups param). And (changing) the latter (to not use strcmp but strcasecmp when converting to code points) would be my thought as to how to implement it in openssl/openssl#26301. The thing that bothers me most in this is that the order of providers/KEM implementations is apparently indeterminate: Is that really so? No way to change that? In case of FIPS provider active, this cannot be acceptable, can it be?

[t8m]

a) How/where/why? I thought the only item of relevance in operation (for groups) is the code point, not the name(?) b) Isn't the KEM registration procedure defining which provider entry points are being called later on? Using names during use would imo be counter-intuitive -- but if you have pointers to code doing that(?), please post them and I correct my (mis-)conception.

The TLS groups are defined via the capabilities such as these for the fips and default providers: https://github.com/openssl/openssl/blob/feature/ml-kem/providers/common/capabilities.c

The TLS code point is just one of the values defined by the TLS group entries. There are also OSSL_CAPABILITY_TLS_GROUP_NAME (the name used in the TLS configuration), OSSL_CAPABILITY_TLS_GROUP_NAME_INTERNAL (the group name passed to the provider as OSSL_PARAM when generating a key), OSSL_CAPABILITY_TLS_GROUP_ALG (the algorithm fetched when generating a key).

These entries ARE NOT directly associated with a provider. libssl will just try to fetch the algorithm from libctx with a name specified by the OSSL_CAPABILITY_TLS_GROUP_ALG value. It will then pass the value of OSSL_CAPABILITY_TLS_GROUP_NAME_INTERNAL as the group name when generating group params to the key generation. We ignore that group name in our provider. Not sure what oqs-provider does.

[adrien-n]

I don't have a very strong opinion on this matter (although I appreciate friendlier names and broader compatibility), especially since nothing in Ubuntu or Debian depends on OQS (unlike for Fedora which has some reverse-dependencies AFAIU). I wanted to mention something however: the fact that distinct algorithm names would avoid accidental use can't be an argument either way because the supporting behavior may change, unless it becomes somehow part of the API of course but I don't think anyone wants to provide more such guarantees.