Mismatched hybrid default OIDs

[bencemali]

It seems to me that there is a discrepancy between the default OIDs of hybrid algorithms listed in the ALGORITHMS.md file and the actual default OIDs assigned in oqsprov/oqsprov.c. For example, the markdown file says that p384_mlkem768 has the default OID 1.3.9999.99.75, while it is actually assigned the 1.3.9999.99.31 OID. I found quite a few of these, but didn't bother checking all of them. Am I missing something or should they be the same?
Btw I found these while writing interop tests between oqs-provider and a hybridization PR I opened to the C# bouncy castle repo. I haven't yet received any feedback if they are actually open to merging something like this.

[baentsch]

Thanks for this report. The markdown file should be generated by what is in generate.yml. If it is not, we've got a serious problem indeed (I didn't check this any more assuming this to be OK since a long time).

Thanks also for reporting your work on interop testing: This is very helpful for everyone and I cannot imagine the BouncyCastle team not being interested in this given the alignment between OpenSSL and BouncyCastle..

[baentsch]

If it is not, we've got a serious problem indeed

After a quick glance before I have to hit the road, the problem is not so bad: The logic generating random OIDs seems to be not working OK. The problem can be easily resolved if one were to add OIDs for all algorithms to generate.yml as per #351. I simply didn't have enough time to scour the world for any possible OID assignment and then decide which ones to use. The "OID generator" logic was thus just a quick fix in #266 to allow all algs to have some OID. Obviously not working flawlessly :-( Given the currently quickly accelerating standardization efforts I'm tempted to remove this completely and let oqsprovider bomb when algorithms are persisted that don't have an OID assigned: That should provide motivation for anyone interested in such algorithm to provide help as per #351.

[baentsch]

I'm tempted to remove this completely and let oqsprovider bomb when algorithms are persisted that don't have an OID assigned

That's what's now happening if #522 lands. Albeit "bomb" is too strong a word -- a normal openssl error event is triggered when KEMs without registered OIDs are used.