On Tue, Dec 21, 2021 at 3:59 AM Vittorio Bertola <vittorio.bertola@xxxxxxxxxxxxxxxx> wrote:
Il 20/12/2021 19:28 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> ha scritto:
So which would people prefer for the pseudo-delegation?
alice.mesh or alice.mesh.arpa?
This would be a reservation in .arpa, not a delegation.While I am interested in potential future alternatives to the DNS, your plan involves selling domain names in your own TLD, even if they are just gateways to paid names in your own alt namespace.
The callsign proposal has the following objectives:
1) To provide permanent names to Internet users (not organizations)
2) To establish user-centric PKI by a binding of names to public keys by definition
3) To eliminate the elements of the DNS architecture that lead to the greatest costs.
The fact that the names can map to names in a DNS space is secondary except to the extent that it fixes some real holes in the DNSSEC trust morel.
I spent decades trying to work out how to validate email addresses like alice@xxxxxxxxxxx. There is no way to make it work well unless Alice owns example.com. Then I started working of the problem of how to transfer Alice's mesh account service from example.com to example.net.
Every Mesh user has a personal root of trust which is a fingerprint of a public key they control and is threshold shared across their devices. So Alice's root of trust fingerprint might be MCM4-ZJWE-RSWW-D6VX-KZDN-J5PU-5GHA.
All I needed to do to allow Alice to transfer her account from alice@xxxxxxxxxxx to alice@xxxxxxxxxxx was for Alice to sign an assertion to that effect under MCMA-... and upload it to some MIT Key Server like infrastructure.
And then as I speced out that system and started ordering hardware, I realized I can go one better, assigning callsigns on a first come first served basis adds nothing to the technical cost (huge legal etc. but technical unchanged). And if it is the act of registering hey key fingerprint that causes the name binding, the registry entries are validated by definition. All I need to do is apply Certificate Transparency/BlockChain ideas to prevent defection by the registry.
The cross notarization structures used by the registry means that if Alice is looking up the registration for @bob, the ultimate root of trust that trust chain Alice will rely on will be MCM4-..., i.e. Alice herself. Every Mesh user is their own ultimate root of trust.
So the DNS names are really a side show here. Except that they share the same trust structure and they don't expire. Which makes it much easier for Alice to use IETF protocols to manage her IoT devices because they bind to names that do not expire.
If you want to sell domain names in your own TLD, you go to ICANN and apply and pay for it just like everyone else has been doing: I see no reason why the IETF should cooperate so that you can bypass the existing rules, and doing so would enrage basically everyone else in the Internet governance sphere.
That is not how I would put it. A lot of people were extremely upset when we built the Web. And before that the telcos were even more upset about the Internet and packet data. If you aren't upsetting anyone, it's because you aren't doing anything useful.
It is not the function of IETF to support ICANN or its business model. The only constituency the IETF should answer to is its users.
Alternatively, you set this up as an alt TLD, and if people see value in it they will install browser plugins or configure their resolvers so that it works for them. I wouldn't see anything bad in this.
Or they will switch to a browser that comes with the capability bundled.
