mgnp: service identity design

[hawkw]

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:

• guaranteed global uniqueness for free
• services can attest the data as having come from the address you wanted to route to
• identities can move across machines if a service can carry its own key material with it
• you don't need to build a whole PKI if addresses are public keys
• some extremely brain genius crypto stuff i'll let henry talk about

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.

[hdevalence]

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]

Not against this, especially if we end up using ephemeral (and shorter) link-ids in every packet, rather than a whole 32-byte ID.

It'd be a shame to have 64-bytes of src/dst in every message, but having that for connection seems reasonable to me.