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

ne 13. 4. 2025 v 5:33 odesílatel a <a@trwnh.com> napsal:

> > 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.
>

That’s not how the Linked Data standards work.

{
  "id": "https://mastodon.social/users/Gargron",
  "type": "Person",
  "publicKey": {
    "id": "https://mastodon.social/users/Gargron#main-key",
    ...
  }
}

This says that a Person has a public key — not a server. The semantics of
RDF and JSON-LD are explicit here: the publicKey is a property of the
entity identified as a Person, which in practice represents a user.


>
> > 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
>