Re: HTTP Signature CG report

Ah wait, you meant the activity ID, not the signer ID. So, n/m, ignore my
previous statement :)

> There is no way to avoid this vulnerability without 1) making keys
server-private or 2) throwing out HTTP Signatures entirely and resolving
every incoming activity.

Strongly disagree. The 'no way to avoid' is only that way due to possible
mis-understanding on how client side sigs work on the side of current
server implementers.


On Wed, Feb 7, 2024 at 11:43 AM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> > If clients have custody of keys, then `foo@example.com` could wait for `
> bar@example.com` to make a post, and then sign an activity with the same
> ID (e.g. "example.com/posts/102930")
>
> Wait, that's not how client signing works tho. The whole point of client
> signing is that nobody else can sign with the same ID (cause they don't
> have your keys).
>
>
>