Is there any specific reason to have separate public/private keys for every single actor, rather than just using a single instance-wide public/private key pair?
I was checking out this document here and it kinda implies that there is no need for every actor to have their own key. The procedure (as I understand it) should work even if all actors use the same key.
The server is in control of all the keys anyway. So why create a new key pair for every actor? It seems redundant/unnecessary. Is it mostly for future compatibility, for instance for a possible future with end-to-end encryption? Or is it that if a private key got leaked or broken, it’s at least only for one actor and not all actors?
Are there any implementations that assume that every actor has their own key pair and wouldn’t work with a single key pair?
Hm, I think there was a reason, but I can’t remember it. In rdf-pub I generate a separate key pair for each profile. And I certainly didn’t do that because it was fun
Unfortunately, I haven’t gotten around to testing it yet because a design error forced me to adapt the entire domain model. It’s only been the last few days that I’ve been working on a working version again.
That does sound like a viable solution, although how do you decide the size of that cache? It would still grow more and more, the more active remote users you get.
If most other instances you federate with also use a single instance keypairs, you don’t need to store any duplicates. In SQL use a foreign key for storing actor public keys which are in a separate table. Then for each instance you will only have a single value.
