[saag] Re: A simpler form of OID

On Wed, Sep 17, 2025 at 2:18 PM Nico Williams <[email protected]> wrote:

> On Wed, Sep 17, 2025 at 12:38:03PM -0400, Phillip Hallam-Baker wrote:
> > 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.
>
> Oh wait, you're proposing an OID-like object but with a different
> namespace managed by IANA.  By having a single registry we'd solve most
> of the problems with OIDs, and we could have each registration include
> document references, user-friendly descriptor, and even URNs.
>

Yup. OIDs fall foul of what I call 'taxonomification', the irrational urge
to sort everything into one true hierarchy of meaning. I hate folder based
file storage for the same reason, the understanding of the taxonomy is
always emergent, you end up in debates on what arcs to place the OIDs.


> These would be a compression of URNs/whatever in many cases.
>
> I'd be happy with such a thing.  Except that you want a namespace of all
> these OID-like things for just one protocol (or, well, I think you meant
> just cryptographic algorithms), and that seems too restricted.  We might
> as well have this be much more generic.
>

This is the result of paring down my UDF proposal to only the exact set of
features needed to implement the @nyone profile of JSContact. The full
scheme has nonces, key generation functions, Shamir secret shares. We can
always do those separately.



> > This would be backed by an IANA registry (of course) with the following
> > rules:
> >
> > Number of Octets
> >
> > 1-2: Standards Action Required [Special]
> > 3-4: Standards Action Required
> > 5-6: Specification and expert review Required
> > 7-15: First come first served.
> > 16-64: Open Season
>
> I'd like this to have more general applicability and to be able to
> reserve sub-namespaces to specific protocols, just as with OIDs we
> can reserve sub-namespaces to registrants.  Then IANA would only accept
> registrations in those sub-namespaces if they are for the same
> protocols.
>

I would accept that as a matter of registry convenience, provided we didn't
burn all the short prefixes on codes that are not going to be user facing.
But if PKIX had a three digit prefix, I bet they would be able to squeeze
all their items assigned so far into four bytes and that would still be an
improvement on OIDs.

That would also pay benefits when moving from development mode to
production. I would develop with a randomly assigned 15 byte prefix and one
byte thing identifier, then apply for an IANA registration of 4 or 6 bytes
if it actually matters in context.

I want my digest algorithm identifier to be really, really short because
these are going to be things humans might be typing in at some point (hence
base32 not base64 for EARLs). Most applications aren't quite that demanding.

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