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

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

> > the publicKey is a property of the entity identified as a Person, which
> in practice represents a user.
>
> "represents a user" doesn't mean that the user controls the resource. The
> server controls the resource. The server is the agent performing HTTP
> requests. The publicKey doesn't matter for anything beyond acting as a
> verificationMethod for the HTTP request, to avoid an HTTP GET of the
> activity id. (And the activity is then most often discarded, since
> fediverse implementations do not keep around activities and instead care
> only for their objects.^1)
>

Sure — the server may be the one performing the HTTP requests, but that
doesn’t change the semantics of the data. The Person is the subject, and
the publicKey is explicitly a property of that Person.

In RDF terms, this asserts that the identity represented by the Person has
a key. If the key is actually controlled by the server and not the user,
then that breaks the model. It’s precisely this mismatch between declared
semantics and operational reality that creates the security concern.

This is why I think a proper security review — grounded in how Linked Data
is actually being used in AP deployments — is important for the next
charter.


>
> ^1: (Alignment between standards and implementations is another issue, of
> course. For how ActivityPub gets used in the fediverse (syndication of
> posts to followers' servers via a form of JSON-RPC), there is not much
> reliance on Linked Data because even the Note resources are transformed to
> and persisted as statuses in databases.)
>

Received on Sunday, 13 April 2025 05:35:23 UTC