Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

> As AP is deployed, the publicKey links directly to the Actor (e.g.,
Mastodon spec) [1]. That suggests the key represents the user, not the
server

The key does not represent the user. Borrowing from the Security Vocabulary
as used in CID and DID specs, it is merely an `authentication` key to
verify that the delivery wasn't spoofed. At most, the key is associated
with but does not represent the actor. The actor is a resource owned by the
server. The user does not control the actor, and indeed does not control
anything in this architecture -- instead, the user communicates with the
server which manages the actor on their behalf.

> leaking private keys to servers, allowing users to be impersonated — but
we’ve also learned that it’s possible, even practical, for users to hold
their own keys and identities, especially across the wider fediverse.

If you want to put it even more bluntly, users are *always* being
"impersonated" by their servers, by way of actors representing the users
(at least, in the naive case -- actors do not necessarily represent users).
Having a `publicKey` on an actor document does not change this, because the
server controls the actor document and can specify whichever key it wants.
Again, there are implementations that use the same key material for every
actor. This doesn't cause issues because actor identities do not depend on
the key in any way whatsoever. The identifier is an https: URI and the key
can change at any time without logging. In a world where the actor document
is an HTTP resource, then anyone who controls the HTTP server can alter the
response at any time. You end up having to trust not only the DNS response,
but also the HTTP response.

Ultimately, the "promise of secure federation" is something that must not
be oversold. We can certainly "explore models where users control their own
keys, not the servers", but this requires making users into agents, and
brings with it a bunch of sweeping changes to the point that https: URIs
are probably no longer sufficient. I am not sure that implementers want to
make such a transition in all cases, but there is certainly work being done
to develop a PKI that could work for the fediverse. I think did:webvh aims
to do something like this, and I think that fedi-e2ee might be working on
something similar (with a public key directory outside of ActivityPub). But
we need to recognize that this model is wildly different to the current
model of HTTPS servers serving HTTP resources, with HTTP user-agents living
alongside them far away from the user. Servers would need to reinvent
themselves as basic message queues, accepting messages from agents which
are not themselves.

~a