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

from cristiano:

> Summing up, the server sends a message, and this message is not
necessarily that produced by the client

from emelia:

> For now, for how the keypair is used within ActivityPub for HTTP Message
Signatures, allowing the server you trust to be custodian of the keys is
fine

---

given the current architecture of "the fediverse", and in many ways the
logical implications of ActivityPub's design, the server is an agent
delivering messages which can at best be described as "on behalf of" or
"using the same material as" the actor, where even in C2S the actor's
messages to the server are consumed and discarded. so client-signed
activities are currently impossible unless you drop down and do raw Linked
Data Notifications where the client itself POSTs to the desired inboxes.

in other words, actors are not agents; they are representative resources
that live on the server. the server is the only real agent.

in RDF terms, any activities submitted to the outbox are necessarily
different from the activities that get delivered via LDN. they have
different ids. the activity POSTed to the outbox has a blank node
identifier. it is used as material to publish and/or deliver an activity
which may appear very similar but is a fundamentally different activity...

...in much the same way as two keys sharing the same key material are
technically distinct. this is also a thing that some implementations do,
where a single keypair is used for every actor on the server. this is not a
security issue because the server owns and controls everything, not just
keys.

if anyone wants to treat clients as agents, then there is a lot more work
to be done to break away from the instance model. this work would be a
pre-requisite to any sort of client-side key management.

~a