so https://host/thing is not the same as http://host/thing -- at best, the http redirects to https

another interesting tangent is that per RFC 4501 https://www.rfc-editor.org/rfc/rfc4501 you can refer to dns://1.1.1.1/trwnh.com as "what Cloudflare DNS returns when queried for the name `trwnh.com`"

but there's no way to authoritatively refer to "thing on host" without specifying an access method and protocol, which is to say that there's no way to know ahead-of-time that //host/thing is the same thing across.

@trwnh ... DNS tries to use DNSSEC to bring some layer of security to name delegation, but it all hangs off a trust anchor in the root zone. Global sources of truth are rarely a good idea, historically speaking, but that's how DNS is built.

But once you've resolved a name with DNS, you then contact that IP address (a locator), and in a TLS handshake negotiate a new security session of sorts. You're trust anchor for the certificates here is not a single source of truth, but a selection of a...

@trwnh ... handful if them. Arguably better.

But that is for the certificate by which the IP address claims that it belongs to the name that DNSSEC provided. But there's no real cryptographic linkage here!

Because DNSSEC effectively only makes a statement about someone having associated a name with a set of IP addresses in one place, and TLS certs make a statement about someone having associated a name with an IP address in another place.

Nobody can verify that these claims are both what...

@trwnh ... is intended by the person who should be making claims about this name and IP address set being linked.

And this is after several decades of using a name to locator resolution system.

There are DNS records for saying more about an endpoint, such as saying that it can speak e.g. https with a particular cert. That finally provides some cryptographic linkage between the two claims (though it still doesn't say much about intent; at least an attacker would have to convince two parties).

@trwnh and in all this, this is about reaching a service, not a resource; we can't know anything about whether a resource is reachable from all of this, or whether it is the resource we want to reach. All we have is yet another name (URL) that could point to anything.

Which is to say that some URL of https://example.com/my-fancy-stuff could simultaneously be a text file and an image to different clients.

So the only way to be sure that a resource is *what* it should be is independent of any naming or...

@jens i thought TLS had nothing to do with IP, and the TLS cert just asserts that you are contacting a certain name (as vouched for by other entities who have their own certs)

so DNS (secured by DNSSEC let's say) gives you a claim that 8.8.8.8 is dns.google

and then TLS gives you a claim that you are handshaking with dns.google

is this wrong?

@trwnh ... locator scheme. The resource itself has to contain the information to verify it. Which in crypto terms means a signature and an identifier of the entity signing it (which needs to be a public key or point to one).

At that point, two rather interesting things happen, namely a) the external name given to the resource via a URI/URL is irrelevant to the resource contents, and b) the location of the resource is irrelevant.

Which makes RNS or whatever a very optional thing. By which...

@trwnh ... I mean your RNS could point you to machine A with a URL, and mine could point me to machine B with some tuple of IP and port (single purpose server only producing that resource), and we'd still be reaching the same resource.

The same, cryptographically certifiable, by the magic of copies.

So names are all well and good, but what we really need are identifiers. People love hashes for those, which for a bunch of reasons I like less, but let's go with that.

The point is that this...

@trwnh ... notion of starting with some kind of name, while intuitive to think about, actually has all kinds of problems that we've been trying to solve for a long time by layering solutions on top of each other, and we're still not talking about the thing that'd actually make a difference (signed resources) *and* that'd make all of these layers rather unnecessary.

I hope that makes sense? I feel like my train of thought might not have been too straight a line

@jens thank you!! i think i disagree with usage of “irrelevant” and “unnecessary” but otherwise understand what you are saying about cryptographic identity.

my conception is you use the name to get to a resource whose contents include some key(s) — kind of like a DID resolver returning a DID document which contains keys. but the identifier is still did:example:whatever so you can’t refer to it without going through the whole DID resolution thing

@trwnh The linkage to the IP comes via the sender address in the IP packet. Yes, that could be spoofed, which is yet another issue. I tried to leave that out

But in principle a cert's name could also be an IP address.

It doesn't really matter for my rant, because that's more about there not being any connection to the resource or its "owner" for lack of a better term.

@trwnh So how do you know you and I get the same keys for did:example:whatever?

It's the same problem again?

@jens the part i am specifically interested in having stable identifiers and stable references. so avoiding link rot.

one way is to have the resource assert its own identifiers, but this is only a unidirectional claim. you’d need to dereference every single claimed alias to be sure. not good!

another way is to make the identifier based in something intrinsic to the resource or thing. for a blob of content, hashing contents works. for mutable descriptors? i’m not sure…

@jens how indeed!

@jens the word the w3c people are using is “controller”

@trwnh No, I'm basically picking random identifiers here, for some definition of random

There's a whole lot of stuff hanging off of that, but the TL;DR is that a random identifier and a signature by the owner is good enough.

It can't prevent a collision, but it can ensure that my foo and your foo are different. Arguably the full identifier then are the tuples (foo, me, sig) and (foo, you, sig). But for most purposes except validation, foo is fine.

@jens so zot_guid and zot_sig, to borrow from prior art…

now here’s the hard part: how do you rotate keys without having to resign every single existing resource?

@trwnh No, no, Zot relies on names again. Really, let's not.

Rotating keys, ah... that leads down a new rabbit hole for which it really is too late.

It's doable, suffice to say!

@jens if you’d like to pick up at some future point i would be interested in hearing more — the tradeoff with key-based identity as i understand it is that key rotation invalidates old signatures. which is afaik why zot uses a random guid and then signs that guid (iirc). sounds a lot like that tuple you were talking about, but it’s been a while since i read the zot protocol docs.

if you have any other resources you can point to in the meantime (heh), i’d appreciate those

@jens really my concern here is that losing a key means losing all your resources and breaking all existing links. i don’t think most people want cryptographic guarantees when alternative means of establishing identity will do fine. for all its problems, people generally trust DNS. can we extend that trust to resources? arbitrary name-to-thing lookup where you can register not just IP addresses but also arbitrary resources? like doi: or isbn: but for anything, by any host