first cut adding ML-*

[baentsch]

This is meant as a test-bed for upstream-triggered CI testing of algorithm-changing PRs such as open-quantum-safe/liboqs#1626

This PR thus replaces #344 introducing ML-KEM and ML-DSA

[ghost]

LGTM! It's nice to see these ML- definitions here :)

[bhess]

ML-KEM (e.g., mlkem512) has the same OID as Kyber (e.g., kyber512), is this intentional?

[baentsch]

Kind-of: In the absence of a spec (or can you point to one, @bhess ?) I took the OIDs chosen by the IETF hackathon (assuming that's the latest ... is it, @praveksharma ?) And if they chose the same OID as for Kyber, well, that points to bad OID management (in this case apparently by the Legions of Bouncy Castle owning that range) and/or the need for someone to take the lead and draft a spec (@dstebila -- what about an "independent" PQ alliance taking that lead?)

[dstebila]

Kind-of: In the absence of a spec (or can you point to one, @bhess ?) I took the OIDs chosen by the IETF hackathon (assuming that's the latest ... is it, @praveksharma ?) And if they chose the same OID as for Kyber, well, that points to bad OID management (in this case apparently by the Legions of Bouncy Castle owning that range) and/or the need for someone to take the lead and draft a spec (@dstebila -- what about an "independent" PQ alliance taking that lead?)

I don't know who is meant to assign the permanent OID for an algorithm -- is it the inventor? the standards body? the first implementer? an alliance? @bhess, if memory serves, IBM assigned some OIDs for earlier rounds of Kyber and Dilithium, are you planning to assign OIDs for ML--ipd or ML-?

[bhess]

NIST usually registers OIDs for approved/standardized algorithms in CSOR. We have in the past reserved OIDs for algorithms used but not already assigned (earlier round versions and ML-DSA-ipd).

[baentsch]

We have in the past reserved OIDs for algorithms used

Please document this in generate.yml as per #351; more people taking responsibility for proper (O)ID allocation very welcome: We could split this task among all of us, e.g., along algorithms: Volunteers welcome!

[bhess]

Looks like all KEM OIDs changed, is this necessary?

[baentsch]

These are generated OIDs, i.e. ones that no-one ever cared about (to specify). I'm thus inclined to leave as-is (and take complaints as indications that they ought to be defined in "generate.yml" -- with the complaints pointing to a spec about whose existence I'd gladly learn).

[bhess]

Fine with me to use generated ones with the absence of specified ones. Just wondering why the PR updates the OIDs of algorithms unrelated to ML-KEM/DSA (e.g., frodo640aes:1.3.9999.99.50 -> 1.3.9999.99.58), did these algorithms change (in liboqs)?

[baentsch]

why the PR updates the OIDs of algorithms

oqs-provider/oqs-template/generate.py

Lines 121 to 125 in 510fea6

	if 'hybrid_oid' in kem: phyb['hybrid_oid']=kem['hybrid_oid']
	else: phyb['hybrid_oid'] = get_tmp_kem_oid()
	kem['hybrids'].insert(0, phyb)
	if not 'oid' in kem:
	kem['oid'] = get_tmp_kem_oid()

[bhess]

Thanks for the pointer, I see two issues with the get_tmp_kem_oid() code.

oqs-provider/oqs-template/generate.py

Lines 95 to 98 in 510fea6

	def get_tmp_kem_oid():
	global kemoidcnt
	kemoidcnt = kemoidcnt+1
	return "1.3.9999.99."+str(kemoidcnt)

• OIDs of unrelated algorithms change if new ones are added: e.g., frodo640aes: 1.3.9999.99.50 -> 1.3.9999.99.58
• OID collisions: e.g., before the PR, OID 1.3.9999.99.54 was for frodo976aes, now the same OID is for x448_bikel3

But maybe I misunderstand the purpose of the temp KEM OIDs. If they are just dummy values not supposed to be globally unique, why not assign the same temp OID for all algorithms without specified OID?

[baentsch]

does OQS Provider support generation of X.509 certs with KEM public keys as the subject public key?

No(t that I knew): How would the cert signature be done in such scenario? These OIDs are solely used to register a KEM en/decoder for public and private keys. Had I known that this would create such a fuzz, I'd never have done #266.

[baentsch]

the OIDs will change when this PR lands, and then change back (!?) when the second PR lands? That seems like it will cause even more chaos.

The OIDs have changed already. They're random, after all -- since October 2023.

[dstebila]

does OQS Provider support generation of X.509 certs with KEM public keys as the subject public key?

No(t that I knew): How would the cert signature be done in such scenario?

The subject's public key can be a KEM / public key encryption key, but the CA must use a digital signature scheme key in order to produce a signature on such a certificate.

[baentsch]

So how is this facilitated using openssl? I for sure have never done this. If you know how to, please contribute a test for this.

[dstebila]

the OIDs will change when this PR lands, and then change back (!?) when the second PR lands? That seems like it will cause even more chaos.

The OIDs have changed already. They're random, after all -- since October 2023.

Did they change in October 2023, or were they introduced in October 2023? I'm looking at 5515b4b#diff-ef6f384f213c1efa6cdc7974fec75a672ce414650acb8ec1f0abdd5984076595R167 which is dated October 5 2023 and it looks to me like this when OIDs for e.g. FrodoKEM were first added, and then they've been stable since them.

[bhess]

Thanks for adding&testing this in parallel to the ML-* addition in liboqs!