Re: HTTP Signature CG report

+1 Evan, on both counts. (I certainly don't mean to imply documenting
current server-side signing is anything but crucial and timely.)

On Wed, Feb 7, 2024 at 12:02 PM Evan Prodromou <evan@prodromou.name> wrote:

> I think it's most important to document the current state of affairs with
> server to server authentication with HTTP Signature.
>
> We have a very good mechanism for fetching data remotely via the proxyUrl
> endpoint. That lets us bridge client to server authentication with server
> to server authentication.
>
> End to end encryption should probably happen in band, and should use
> different keys than those used for server to server authentication.
>
> Evan
>
> On Feb 7, 2024 11:57, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:
>
> Also, let me back up and try to address this on a slightly more abstract
> level.
> Server-side signing is a TEMPORARY state of affairs. Like.. it's not good,
> it's just an artifact of tech limitation (lack of good client-side key
> management options) at the time.
> And it's definitely not the "only secure method" that the previous
> discussion is implying, but exactly the opposite (something we have to put
> up with currently, but will try to move away from).
>
> If current server implementations don't handle client-side signing
> correctly, that's fine, we'll have to fix that (and painfully wait till the
> fixes propagate through the ecosystem).
> If there's something in the AP protocol that's adding to the confusion /
> making client-side signing harder, we'll fix the protocol.
>
> (Hopefully my answers make more sense in that context.)
>
>
>
>
> On Wed, Feb 7, 2024 at 11:49 AM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
> > There is no way a receiving server can tell that example.com/posts/123 is
> "supposed to" be bar's ID to sign, instead of foo's.
>
> And why's that a problem? (also, let's switch to the usual Alice for legit
> post author and Mallory for the attacker).
> If Alice creates a post and client-side signs it, and then Mallory makes a
> post with the same ID and client-side signs it and sends it to another
> server -- you're right that the receiving server doesn't know who the post
> is "supposed to" belong to.
> However, that doesn't really matter. People who don't subscribe to Mallory
> won't see her posts (they'd only see Alice's posts). Is that not the case?
>
>
>
>
> On Wed, Feb 7, 2024 at 11:46 AM nightpool <eg1290@gmail.com> wrote:
>
> I'm talking about the ID for the activity itself. The Activity is
> attributedTo example.com/users/foo, but it purports to shares an id (
> example.com/posts/123) with a legitimate post made by
> example.com/users/bar. There is no way a receiving server can tell that
> example.com/posts/123 is "supposed to" be bar's ID to sign, instead of
> foo's.
>
> 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).
>
>
>
>