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.