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

Sean, re:

> a plan to implement that is feasible

implement what, and where? if you’re talking about the currently-deployed
softwares and protocols that form the fediverse, then this is essentially a
high-trust local environment with a low-trust remote environment. Any
“heightened security model” needs to start with making actors into agents,
which they currently are not. Servers are the only agents. Any reference to
“user content and messages” needs to recognize that currently, this does
not exist. Any “user content and messages” are consumed as material to
generate a resource on the server. There is nothing for users to sign that
anyone will ever see. You could eliminate keys entirely and move to a model
where activities are authenticated by refetching from origin, and you
wouldn’t lose any security properties — you just get some traffic
inefficiency, and you’d need an access control model.

Please don’t be mistaken and take these as “objections” to the idea of
secure communications, but rather, take them as an analysis whose
conclusion is to use something out-of-band. As currently designed, there
are myriad reasons why the fediverse should not be used for
security-critical messaging, or messaging of any kind for that matter. Even
“direct visibility” should not be thought of as *messaging*; it is treated
as *publishing* a post on your server. The server just so happens to make
the resulting resource available to a limited audience.

Re:

> Well-known threats can be mitigated with a variety of methods of
generating and managing keys

This is describing a PKI which currently does not exist on the fediverse.
Keys are generated and managed by servers because servers are the only
agents. But I invite “significant discussion” while considering “user
expectations” and “existing software limitations”… I just want to preface
such discussion with a clear understanding of the design goals and
tradeoffs without mischaracterizations of the current system for
“publishing” vs. the very different system required for “messaging”. And
they are fundamentally different systems; I don’t think there is a way to
avoid fundamentally rearchitecting the network such that it supports agents
which are not the host service. By the time this “step 1” is done, we’d be
looking at a fundamentally different network of agents with keys, rather
than servers with actors whose identity is rooted in the DNS system.

~a