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

On 9/21/2025 11:09 AM, Phillip Hallam-Baker wrote:
> Argh, nope, my last post is nonsense.
>
> The Type identifier is a name, the combination of a type identifier and a
> digest value is indexical.
>
>
> The advantage of this approach over OIDs is compactness. It allows us to
> assign really short identifiers to the most frequently used algorithms in
> the contexts that most need compactness.
>
> At this point in the process, I just want to get those applications done in
> a way that does not foreclose anything later on. There are three separate
> areas of concern:
>
> 1) Registered names.
> 2) Randomly assigned names.
> 3) Mapping legacy names.

The DNS is pretty good for registered names and legacy names. That's 
what it does.

And you can always use a point in the hierarchy for randomly assigned 
names. Tor does something like that with .onion.

> Registered names can be short or human readable. When the net was starting,
> they were the only names we needed to use. Now the net is very large with
> five billion users and registries aren't going to be able to keep up.

It depends a lot what you ask registries. If the only thing they do is 
"provide ownership of a unique name at some point in the naming tree", 
that can be automated easily, and some of the registries already do 
that. There are more than a billion DNS names already, it is not that 
hard to imagine 5 billion more.

> A second area of concern in these times is that any registry is a potential
> point of control. That is why DNS politics are so fraught with ICANN
> meetings being filled with folk who have held 'cultural attache' posts at
> various embassies.

Yes, but you have to distinguish two kinds of control. One is about 
copyrights, trademarks, or culturally sensitive names. No good way 
there, unless you follow the same strategy as license plates. The other 
is about using the naming system as a choke point, to for example "block 
pirate-bay.de because it is allowing free access to copyrighted 
material" -- or block distribution of a virus. Whatever your system, if 
there is some kind of control point it will have to deal with that. Even 
if the name is just some long random number, some judge is going to ask 
you to block that random number.

> A naming scheme that provides a bridge between all three forms might well
> be advantageous at some point. For the past 25 years, application protocol
> development has essentially been 'how do you layer that over HTTP'. Which
> is a PITA because HTTP is a very limited communication pattern designed for
> a very specific purpose. It only supports subordination. Now we have QUIC
> and cheap TLS certs, it makes good sense to revisit that.

The cheap TLS certs are cheap because they work with the DNS and 
automatically issue certificates upon proof of control of a DNS name. If 
you have something else than DNS, you will need a parallel 
infrastructure to issue certs for your new names. You could automate 
that using names derived from keys, but that requires either or updating 
the QUIC/TLS stack of every client to understand and verify the relation 
between key and name, which has a "boiling the ocean" ring to it, 
or building you own version of something like Let's Encrypt that issues 
a Cert upon verifying key ownership, which merely requires a lot of 
money and having the certification authority accepted by browsers or TLS 
stacks. Pick one...

> All I really get out of the HTTP layer is service separation via the
> .well-known convention and a not particularly efficient chunking scheme
> which was the best we could do in the circumstances. So I am looking
> towards MOQ and similar for future patterns.

MoQ has two communication modes: over HTTPS (including H3/QUIC) using 
web transport, or using native QUIC (no H3 or webtransport layer), and 
in that case identifying the application using the ALPN. QUIC+ALPN is 
certainly a plausible pattern, I used it when writing the DNS over QUIC 
spec, but there are some sticky points. For example, MoQ over HTTPS 
relies on OAUTH for client auth, and you end up having to develop some 
equivalent inside your app when running native QUIC.

> One scheme that might prove interesting is to use SHAKE-256 (well-known,
> dns) as an opaque identifier...

-- Christian Huitema


>
> On Sat, Sep 20, 2025 at 11:53 AM Phillip Hallam-Baker <[email protected]>
> wrote:
>
>>
>> On Fri, Sep 19, 2025 at 6:16 PM Christian Huitema <[email protected]>
>> wrote:
>>
>>> On 9/18/2025 4:20 PM, Nico Williams wrote:
>>>> On Thu, Sep 18, 2025 at 03:32:37PM -0400, Phillip Hallam-Baker wrote:
>>>>> 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.
>>>> This is a UI issue.
>>> Maybe, maybe not. Identifiers do leak into the UI, and there is some
>>> beauty in identifiers being WYSIWIG -- or rather, what you read over the
>>> phone is what you get, as Phill said. So I understand the beauty of an
>>> identifier made of a series of easy to read character strings. But why
>>> insist on Base32? Don't we already have identifiers made of series of
>>> easy to read alpha-numeric strings nicely separated by dots?
>>>
>> DNS Names are Names, signifiers of type thirdness that have a purely
>> conventional relation to the signified.
>>
>> These identifiers are mostly Indexical, signifiers of type secondness
>> having a direct relationship to the thing signified and a few are direct
>> being the thing signified.
>>
>>
>>

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