Or skip all of this complexity and just enroll the naked public key bound to whatever name you like (if any) and having the side benefit of not having to deal with a dinosauric encoding scheme.
https is not the same as TLS. You don't need the TLS name to be bound to the domain but the https name does. And you also have to provide backwards compatibility for 30 years of https browsers.
As I said, x.509 with TLS for https is water under the bridge. My
point is that we don't need to keep thinking that they are the
only way or even the preferred way to implement identity with
asymmetric keys across trust boundaries, and most especially not
when they are within trust boundaries. I've seen people get
completely wrapped around the axle trying to shoehorn enterprise
level certs and just shake my head of what on earth they are
thinking.
We looked at this approach in 1995. Really we did. And the problem is that you aren't avoiding a central point of control, you are pretending ICANN is that point of control. And it isn't up to that role institutionally, nor is DNS suited for that purpose.
So instead we got a whole bunch of trust anchors basically by
fiat. And business models. Lots of business models.
The Mesh callsign registry is designed to support exactly that.
[]
Is this supposed to make me feel better about induced complexity?
Mike
