Document & curate (O)IDs

[baentsch]

The file oqs-template/generate.yml serves as the master file for all algorithm (O)IDs. Due to the absence of standard documents specifying them, most of the IDs chosen are randomly allocated, many manually, many automatically.

As persistence of PQC signature algorithms is a default feature of oqsprovider, OIDs for signature algorithms are manually curated and updated as OID updates are required, e.g., due to algorithm updates.

As persistence of PQC KEM algorithms is a non-default feature of oqsprovider, OIDs for KEM algorithms are mostly automatically generated and therefore not stable across releases.

This issue is to propose changing this with at least the following improvements:

• Document the origin for each (O)ID
• Change automatic OID allocation for KEM algorithms to manually curated allocation, paving the way for making OQS_KEM_ENCODERS a default feature

[baentsch]

I am a bit confused: The IETF hackathon team decided to use the same OIDs for Kyber and ML-KEM, but I thought those algorithms are different (at least they have different KATs): Am I wrong in this assumption? This leads to a c[l|r]ash when activating Kyber and ML-KEM using the same OID. Question to @praveksharma : Have you been part of the IETF hackathon team's decision to give Kyber and ML-KEM the same OIDs/supporting the notion they are functionally equivalent? Also tagging @bhess @dstebila for input.

If so, shall we (also follow the IETF hackathon's lead and) eliminate Kyber entirely from oqsprovider? Or shall we assign either algorithm different OIDs? Which ones? The ones used by the hackathon team IMO cannot be extended as they are in a range controlled by a commercial entity (prefix "1.3.6.1.4.1.").

May I propose @bhess takes on responsibility for managing the Kyber/Dilithium/ML-KEM/ML-DSA ID range and resolve this particular conundrum?

Given we have introduced the capability of encoding KEMs solely for interop testing (and to resolve #194), what about adding a statement along the lines "This feature is experimental until a solid management of KEM OIDs is established. Use at your own risk." to the documentation of OQS_KEM_ENCODERS and remove it from CI until we have properly resolved this issue? Also adding @Muzosh @ralienpp for input as they've been part of the discussions in #194.

[ounsworth]

I am a bit confused: The IETF hackathon team decided to use the same OIDs for Kyber and ML-KEM, but I thought those algorithms are different

No, that's wrong. You are correct that there are interop differences between "round 3 kyber" and "initial public draft ML-KEM".

If you check the hackathon oids table:
https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/oid_mapping.md

you will see that we have new OIDs for the ml-kem-ipd. NIST will provide final OIDs with the final versions of the FIPS documents.

[bhess]

May I propose @bhess takes on responsibility for managing the Kyber/Dilithium/ML-KEM/ML-DSA ID range and resolve this particular conundrum?

We have the following Kyber-r3 OIDs registered under the IBM tree, which could be used:

• Kyber512: 1.3.6.1.4.1.2.267.8.2.2
• Kyber768: 1.3.6.1.4.1.2.267.8.3.3
• Kyber1024: 1.3.6.1.4.1.2.267.8.4.4

The Dilithium and ML-DSA-ipd OIDs are correctly reflected in https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/oid_mapping.md

[baentsch]

We have the following Kyber-r3 OIDs registered under the IBM tree

Very good, thanks. May I invite a PR (similar to #361) tying these down, then?

[baentsch]

I am a bit confused: The IETF hackathon team decided to use the same OIDs for Kyber and ML-KEM, but I thought those algorithms are different

No, that's wrong.

Hmm, looking at IETF-Hackathon/pqc-certificates@42c76ac it seems OIDs were not changed, but the algorithm names "Kyber-..." were simply replaced by "ML-KEM-...".

You are correct that there are interop differences between "round 3 kyber" and "initial public draft ML-KEM".

If you check the hackathon oids table: https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/oid_mapping.md

you will see that we have new OIDs for the ml-kem-ipd. NIST will provide final OIDs with the final versions of the FIPS documents.

The current "schism" is resolved by IBM taking responsibility for Kyber OIDs. Looking forward to NIST eventually taking responsibility for ML-... OIDs.

[Muzosh]

I guess the same discussion could be applied not only to Kyber, but Sphincs+ as well for example.

OQS's ALGORITHMS page originally lists 1.3.9999.6.4.16 for sphincssha2128ssimple.

IETF Hackathon seems to have renamed it to SLH-DSA-SHA2-128s-ipd under the same OID.

[Muzosh]

Also, why only the ML-KEM (and in IETF Hackathon's case, couple of more algorithms like BIKE and HQC) is listed under the OID space of The legion of Bouncy Castle? (= 1.3.6.1.4.1.22554...), while all the rest is either under IBM (= 1.3.6.1.4.1.2...) or reserved space (= 1.3.9999..)?

[Muzosh]

Btw I really appreciate @baentsch's efforts in this github issue. The current OID space is a wild west and we need some (at least un-official) standardization of OID list in order to save security engineers and developers hours of internet digging.

[bhess]

To document the OIDs of the NIST standards (from https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration):

nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) }

kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }
id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }
id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }
id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 }

sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }
id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 }
id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 }
id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 }
id-hash-ml-dsa-44-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 32 }
id-hash-ml-dsa-65-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 33 }
id-hash-ml-dsa-87-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 34 }

id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }
id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }
id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }
id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }
id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }
id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }
id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }
id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }
id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }
id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }
id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }
id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }
id-hash-slh-dsa-sha2-128s-with-sha256 OBJECT IDENTIFIER ::= { sigAlgs 35 }
id-hash-slh-dsa-sha2-128f-with-sha256 OBJECT IDENTIFIER ::= { sigAlgs 36 }
id-hash-slh-dsa-sha2-192s-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 37 }
id-hash-slh-dsa-sha2-192f-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 38 }
id-hash-slh-dsa-sha2-256s-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 39 }
id-hash-slh-dsa-sha2-256f-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 40 }
id-hash-slh-dsa-shake-128s-with-shake128 OBJECT IDENTIFIER ::= { sigAlgs 41 }
id-hash-slh-dsa-shake-128f-with-shake128 OBJECT IDENTIFIER ::= { sigAlgs 42 }
id-hash-slh-dsa-shake-192s-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 43 }
id-hash-slh-dsa-shake-192f-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 44 }
id-hash-slh-dsa-shake-256s-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 45 }
id-hash-slh-dsa-shake-256f-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 46 }