[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02 : recommended, MTI, OIDx

On 2/17/2025 10:48 AM, Salz, Rich wrote:
>>>> Hrm. This points to another reason to promote IANA registries instead of (or in addition to) OIDs.
>>> I don't think so. OIDs can be created and used by anyone, but OIDs not in a standards-track RFC seem to me just like private-use identifiers.
>> Maybe you don't deal much with PKIX or CMS. The OIDs there are absolutely the way that the cryptographic components are identified.
> Yes, I know.
>
> I guess I wasn't clear.  Anyone can define an OID and use it in an RFC.  I am saying that if that RFC is Informational, not in the IETF stream, or anything else -- THAT IS NOT STANDARDS-TRACK -- then there is little noticeable difference between that(those) OID and private-use space in an IANA registry.  Using your example, I can define a new PKCS#8 private key type that and publish an Individual draft or Experimental. But unless it came from LAMPS and is on the standards track, it's just (er) yelling into the wind, or a private-use identifier.

OID have the property of being unique. That is only one of the functions 
of the registry. The other functions are:

* being well known, a.k.a., "the spec is available"

* having a documented recommendation produced by WG or experts, from 
"recommended" or "mandatory" to "maybe not", using terminology generally 
chosen by the WG.

You could achieve those other functions by registering an OID in the 
IANA registry, but that forces the registry to verify that this OID is 
indeed unique, e.g., use an organization code that is properly 
registered, and that whoever asks for the registration is authorized to 
use names under that OID branch. That's an extra burden for IANA. Other 
methods, like large random numbers, are somewhat easier to manage.

-- Christian Huitema

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]