Design-principles review

[baentsch]

oqsprovider has been designed around internal and external design goals, some of which are called into question by issues like #617, #610, #621, #623. This discussion is to list them and ask the community for opinions as to whether the goals should be changed and/or whether the strawman re-design proposal contained is OK for everyone

Goals

Internal

1 Generate all algorithm-specific code from one central configuration file
2 Do not contain algorithm-specific code that is not generated

External

3 Do not differentiate between algorithm names, irrespective of the context in which they are used
4 Work in all openssl APIs (>= 3.0.0)
5 Retain names available in existing releases of oqsprovider.

Strawman re-design proposal:

• Add case-sensitive fields labelled "std_tls_name" and "std_alg_name" as optional parameters to config.yml for each top-level KEM entry and each variant level SIG entry. If omitted from the config file, the new fields shall be auto-populated via generate.py with the pre-existing mandatory values held by "name_group" for KEMs and "name" for SIGs, respectively. This will retain the current naming for algorithms following goal 3 above.
• Do not fail in registering any algorithm via c_obj_create or c_obj_add_sigid any more. This will allow oqsprovider to still register successfully in openssl 3.5, fulfilling goal 4 above.
• Dynamically update the stored OID/algname table with the name possibly already registered via openssl built-in providers (and retrievable via OBJ_nid2sn(OBJ_txt2nid(OID))
• Correspondingly update the NID/algname table with the contents of "std_alg_name"
• When registering the algorithms via the corresponding macros, augment the current NAMES field with the "std_alg_name" field in the leading position, with the pre-existing "name[_group]" as an alias
• When registering groups via the OQS_GROUP_ENTRY macro change to use the "std_tls_name" value
• Correspondingly, when registering TLS signature algorithms via the OQS_SIGALG_ENTRY change to use the "std_tls_name" value

Overall, this approach should also retain goals 1 and 2.

Goal 5 cannot be upheld as discussed here.

Alternative suggestions or PRs welcome. Also welcome proposals to change goals.

If no feedback is received, this might be implemented as documented above by the time ML-DSA and ML-KEM have landed in openssl master and if there is commitment to contribute work for keeping support for standardized algorithms as per #610.

[levitte]

When registering the algorithms via the corresponding macros, also include the OID. Example:

    SIGALG("mldsa44:2.16.840.1.101.3.4.3.17", 128, oqs_signature_functions),

[baentsch]

Note (probably to self), don't use sn2nid as per #629 (comment)