[saag] Re: Relative OIDs are the simpler form of OID (Re : A simpler form of OID)

OK, so I do want to keep hold of my 'can type identifier in BASE-32'
constraint. Because that allows an identifier to be read over a telephone.

So if we were going to go 'all in' on mapping everything to a Type
identifier, I would start with an initial byte that gives us an O (113) and
then look into some compact mapping of the OID segments to bytes.

[And probably do that for UUIDs as well with an initial letter U (161)]

We could probably make the resulting sequences shorter than the OID forms
as the code points we mostly use come off a tiny number of arcs, consider
the PKIX prefix:

      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
                 dod(6) internet(1) security(5) mechanisms(5) pkix(7) }


I suspect most of the OIDS we use come off either the NIST crypto arc, DOD
Internet arc, the IANA private assignment arc or the IANA Internet arc.

One side effect of this scheme is that we have an automatic means of
converting OIDs to short ascii strings that we can then use in JOSE, XML
digsig, etc.

For example, SHA-3 is 1.3.14.3.2.26, if we assume that we 1.3.14 is an
assigned prefix, and we are encoding each segment in 6 bits, that requires
5 bytes, same as for the ASN.1 encoding. The Base32-D presentation is going
to be something like OF30-29JE-3R. OK, so not as short or mnemonic as SHA3,
but it is a way of keeping vanity crypto out of IETF and IRTF process and
if I am debugging stuff, I can see that there is an O there and will be
thinking, 'it is an OID and this is likely an algorithm I should look up'.

And since SHA-3 is one of the algorithms I think is going to be core for
using digests, I am proposing a single byte prefix anyway.


This stuff all looks pretty straightforward but it isn't stuff I have an
immediate need for. What I propose to do going forward is propose JUST the
DARE Envelope and EARL schemes to the JOSE working group as proposed in
DISPATCH with a section in the EARL draft that says 'create a Type
Identifier Registry and populate it with these initial values used in the
EARL scheme:

[32] Verbatim, Encrypted, SHA-3 + AES-GCM
[34] Enveloped, Encrypted,  SHA-3 + AES-GCM
[80] Verbatim, Plaintext, SHA3
[82] Enveloped, Plaintext, SHA3

The only other code point I could justify on the basis of my current work
is the nonce type identifier (104, N). And the reason for calling out
nonces is merely that if you are reading data, it is really useful to know
that there SHOULD NOT be any additional encoded data there [and if there is
meaning encoded in the nonce value, you have some kleptography and a side
channel attack going on there].




On Thu, Sep 18, 2025 at 11:36 AM Nico Williams <[email protected]>
wrote:

> On Thu, Sep 18, 2025 at 10:44:09AM +0200, Carsten Bormann wrote:
> > On 2025-09-18, at 07:50, Nico Williams <[email protected]> wrote:
> > > RELATIVE-OID
> >
> > CBOR has a tag (extended data type) for this (tag number 110, see RFC
> 9090), for pretty much the reasons given.
>
> About 20 years ago we considered using relative OIDs for new typed holes
> in Kerberos also for these reasons.
>
> Every OID codec has a relative OID codec hiding inside it.  So we're
> talking about spec and code reuse.
>
> I think that's the right approach for Phillip.
>
> Nico
> --
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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