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.
So I just discovered that Mastodon actually requires the actor holding the key to be the same actor as the one sending the activity. So for example you can’t just refer to the key of the instance actor when sending a follow request from a usual user, which is a bit annoying.
Is Mastodon’s behavior here correct? I don’t see anything in the HTTP Signatures documentation that’s says these two actors must be the same actor. I understand that their domains must be equal, as you could otherwise easily impersonate someone, but if they are within the same instance, isn’t it fine then?
The key may not even have an owner. Having id with the same domain as activity id is enough to establish trust (I published a FEP about that: FEP-fe34: Origin-based security model).
Mastodon could relax the requirement, but I wouldn’t say its behavior is incorrect, because there is no standard. I think it is a remnant of actor-centric view ActivityPub, towards which network was supposed to evolve, but never did.
That’s fair, it does seem like the whole HTTP Signature + ActivityPub situation is kind of in a weird unfinished/unspecified state. Only just found out today that the updated standard is incompatible with the current usage and I wonder how long it would take to actually get that updated throughout the ecosystem…
