Prototype OID-based versioning

[kriskwiatkowski]

OID

We suggest having the following format of an OID x.y.z.A.V.P, where:

• x.y.z: OID prefix - to be decided
• A: identifier of an algorithm
• V: version of an algorithm specification. Value is scheme specific, 0 is used in case specification has no version.
• P: parameter set (a.k.a. NIST security level)

Example: Let say we have following OID 1.3.6.1.4.1.2.9.31.3, then:

• 1.3.6.1.4.1.2 is a common prefix for all PQ schemes (x.y.z). Actual value to be decided.
• 9 identifier of PQ scheme (let say Dilithium)
• 31 version of a specification (here Dilithium 3.1)
• 3 parameter set (here, Dilithium 3)

[pkelsey]

The interpretation of the value of the version arc should be scheme-specific, so as not to assume that every version of every PQ scheme will be identifiable by a major.minor version number where minor <= 9.

[kriskwiatkowski]

@pkelsey Agreed. That is the assumption - the value V is specific to a scheme. I've added explenation above.

[kriskwiatkowski]

Question: Schemes they have their own versioning, but IETF drafts also have versioning. ASN.1 structures may differ between draft versions. For better interoperability, I wonder if OID should also contain a version of a draft? Thoughts?

[baentsch]

if OID should also contain a version of a draft?

If different draft versions change anything that's externally represented/persistent (certs, keys, etc), then I'd say so.

For interop testing, though, I'd find a mapping "generally accepted algorithm name (and version)" <-> OID <-> "implementation algorithm name" (the latter mapping in combination with the ability to set OIDs dynamically) most helpful.

[johngray-dev]

I agree with these comments. So I think we should propose a set of OIDs that follow this convention. We can discuss this at our next monthly meeting on December 5th.

[johngray-dev]

We now have a mix of standard OIDs (For ML-KEM, ML-DSA, SLH-DSA) and prototype OIDs for the up coming algorithms.

We have essentially been using the rule:

"The first implementation to submit an algorithm that requires a prototype OID gets to decide the prototype OID".

That has helped to make it easier to manage through multiple changes as we don't have to force the implementer to change their OIDs, and in fact we wouldn't have a way to force them to change them anyway because we don't have control over their implementation. For example, LibOQS or bouncy castle API's had defined some prototype OIDs for their own implementations out of need, and it just ended up being easier for this group to agree to adopt those OIDs for interop testing.

So I think we can suggest that when prototype OIDs are selected by an implementation, these rules get adopted but we can easily accomodate when they don't.