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

On Sun, Sep 21, 2025 at 3:16 PM Christian Huitema <[email protected]>
wrote:

>
> 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.


Which is why human readable becomes expensive. It is also why OIDs became
problematic, having an OID in the IETF or NIST arc makes a difference to
some.

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.
>

That is not the concern that caused the French government to block a
registry of RFID tokens we were involved with at a former employer. Their
concern was that the registry being a part of the DNS meant that a future
US government might come along and say 'Airbus doesn't get any more code
points registered'.

That seemed to be an absurd concern to some back then (not to me). It is
certainly not absurd today.




> > 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.


They are cheap because Google underwrote the cost of production because
certain ISPs were stealing advertising dollars from Google by replacing the
ads placed by the content provider with ads sold by the ISP.

If you want to do cheap cryptographic credentials, the way to do that would
be to make the registration for the name include registering the root of
trust for the certs.


> If you have something else than DNS, you will need a parallel
> infrastructure to issue certs for your new names.


I am not making a proposal of that sort at the moment but that is not true.

What you would do is what I proposed in my Callsigns scheme: Names are
First Come First Served with some sort of redress scheme to deter name
squatting, registrations do not expire, a registration consists of a
binding of a name to the public key controlling use of the name (signing
DNSSEC entries, issuing TLS certs). Registry does not provide resolution
services, it just publishes updates to the registry in the form of an
append only log.

Cost of running such a registry could be made negligible to registrants.


> 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...
>

I have the backwards integration all worked out, it would require a new
ACME authentication mechanism but otherwise can be made to fit in the
legacy framework. The reason I am not pushing that at the moment is because
1) the @nyone profile for JSContact solves the same set of problems for a
larger number of people in a shorter period of time and 2) unlike the DANE
folk whose big idea was getting DNS registrars to eliminate their main
source of earnings, I understand the business relationships in DNS world
and that you are unlikely to get DNS Registrars onboard with a DNS Handles
scheme if you are also trying to make registrations free and for life.



> > 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.
>

That is why I think we the Blue Sky profile of OAUTH could be so important.
The problem with OAUTH at the moment is that the technology is over a
decade old, there are many different flavors and the dominant
implementation means that it is not an open system at all, it is a closed
shop and only Google, Facebook and to a lesser extent Apple remain as
widely accepted IdPs.

The ATprotocol profile being bound to a DNS name means that I can
effectively control my own destiny, I am not tied to the Blue Sky IdP, I
can even run my own. There is no cartel that people have to join to run the
service.

Now yes, OAUTH is a protocol that is designed to do a limited range of
things and it is a poor match for a lot of the things I would want to use
MOQ for. In particular, I want my security cameras streaming video over MOQ
and I certainly do not want to have them calling out to an extraneous IdP.
Fortunately, TLS Client Auth is a very good match for those.

The situation is very similar to that with 802.11b before the WiFi brand
and profile were established.

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