[saag] Re: A simpler form of OID

On Wed, Sep 17, 2025 at 12:38:03PM -0400, Phillip Hallam-Baker wrote:
> The one thing I really, really like from ASN.1 that I haven't seen an
> equivalent of in XML or JSON is the OID, an extensible identifier format
> whose length is self describing. That is a building block I would really
> like in any binary protocol.

If we had a resolution protocol to turn dotter number OID notation to
notation with arc names, or even into URNs (and back, for URNs
associated with OIDs), I'd agree that OIDs are really nice as a binary
object.  But OIDs in APIs, like in the GSS-API [RFC 2743]?  No.

> The downside of OIDs is of course the need for a registry, the format is
> fiddly, etc. etc. But I do really like the notion that I can simply splice
> a variable length sequence of octets into a stream and be guaranteed I have
> a unique ID.

The downsides of OIDs are many:

 - they are ugly and meaningless if shown to humans, and they do tend to
   leak into UIs, sadly

 - there are no tools for setting up registries, so often they don't
   exist

 - there is no resolution protocol for arc names

Might as well use URNs.  At least if URNs leak into UIs users can
recognize them as such and search for them, plus often the URNs are
somewhat self-describing.

> So I had a bunch of thoughts on using variants for the purpose and suddenly
> realized there is a much simpler approach than specifying the conversion of
> integers to strings of octets: The octet sequence is sufficient.
> 
> So a type identifier is simply a sequence of octets in which the final
> octet is even and all the others are odd, e.g:
> 
> [00]
> [01 00]
> [23 13 68]
> [67 25 93 93 42]

In source code for software that uses OIDs you tend to see their DER
encodings in binary string literals.

Nico
-- 

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