hdevalence
commented
8 months ago Yeah! The big insight here is that if you make cryptographic keys the root of identity, you don't need a PKI, because the keys are already the identities. (You then have to figure out how to manage those keys, so it's really more of a "problem changed", but it's a good change, because it's easier to associate human-readable names to cryptographic keys than vice versa)
jamesmunns
we need a real design for service identity --- currently we just have a sort of "finish this later" sketch.
@hdevalence suggests using ed25519 public keys for service instance addresses, and i think this is probably the right approach. i'd like to be able to layer in an encrypted transport for untrusted links layer, and using the pubkey as the address gives us a lot of benefits:
this does have the downside making addresses be 32 bytes long (twice the size of an IPv6 addr...). however, if you wanted to add transport encryption on top of a routing protocol, you would still be exchanging pubkeys in addition to routing addrs, so there is maybe some advantage to not having to exchange both.
another downside is that you can't easily use a scheme based on pubkeys to represent hierarchical addresses, the way you can with IP subnets. but maybe we will use a routing scheme that doesn't require that?
meanwhile, i think we should continue using UUIDs to identify service interfaces. so, a UUID identifies a particular RPC interface that a service serves, while a public key is the address of an individual service that you can route to.
you could do service discovery by, essentially, asking a discovery service (who you trust) "hey, i want someone who provides the service interface with this UUID" and getting back a set of ed25519 pub keys (addresses) that serve the service you wanted. since the discovery service signed the messages with its private key, you create a chain of trust for the discovered endpoints implicitly.